Nsdateformatter Still Parsing Instead Having Incorrect Format

NSDateFormatter, am I doing something wrong or is this a bug?

Using the code you posted on both the simulator and a phone with the 2.1 firmware and 24-hour time set to off, I never had an AM/PM appended to dateStr when I do:

NSLog(@"%@", dateStr);

Are you doing anything else with dateStr that you didn't post here? How are you checking the value?

Follow up

Try turning the am/pm setting on then off. I didn't have the problem either, until I did that. I am printing it out the same way you are.

Okay, I see it when I do this also. It's gotta be a bug. I recommend you file a bug report and just check for and filter out the unwanted characters in the meantime.

NSDateFormatter return wrong date + Swift

When you convert from string to NSDate, if you do not set the timezone to the formatter, you will get the NSDate of a date in your local time zone. I suppose that your time zone is GMT+3 .

Then, when you show the value of 'date' (using println, NSLog but not NSDateFormatter), without setting the time zone, you will get GMT+0 time. That why you got 3h later.

Depend on how to use NSDateFormatter, you will have the date string as you want. In your case, It returns what you want, doesn't it?

Remember that NSDate presents a moment of time.

let dateString = "2016-04-02"
let formatter = NSDateFormatter()
formatter.dateFormat = "yyyy-MM-dd"
println("dateString: \(dateString)")

formatter.locale =  NSLocale(localeIdentifier: "en_US_POSIX")
let date = formatter.dateFromString(dateString) //without specify timezone, your dateString "2016-04-02" is your local time (GMT-3),  
//means it's 2016-04-02 00:00:000 at GMT+0. That is the value that NSDate holds.

println("date: \(date)") //that why it show 2016-04-01 21:00:000, but not 2016-04-02 00:00:000

formatter.dateFormat = "yyyy-MM-dd"
let formattedDateString = formatter.stringFromDate(date!)
println("formattedDateString: \(formattedDateString)")

How to convert string to date correctly?

I will say more - it also works unexpectedly

let dateFormatter = DateFormatter()
dateFormatter.dateFormat = "yyyy-MM-dd"

let dotDate = dateFormatter.date(from: "2020....07...10") // Optional(2020-07-09 21:00:00 +0000)
let commaDate = dateFormatter.date(from: "2020,,,,07,,,,10") // Optional(2020-07-09 21:00:00 +0000)

My version is probably the issue in internal implementation on Apple side and comparison with the ASCII code table, where the codes of these characters (,,-,.,/) are in order (from 44 to 47)

NSDateFormatter fails with string that seems correct

The error was caused because that date doesn't exist under the Chilean zone (due to DST change).

While NSDateFormatter is correct to return nil because it doesn't exist. It's not feasible to tell the user "The file was created in a time your timezone never experienced".

The solution (that applies to any other zone with DST) is to set a timezone just like the current one without DST.

NSString *dateString = ...; //Assume it is defined
NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
[formatter setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss"];
NSLocale *locale = [NSLocale localeWithLocaleIdentifier:@"en_US_POSIX"];
[formatter setLocale:locale];
//Date formatting might fail because of Daylight Saving Timezones and the like. So, we force the timezone to one just like it where the date always exist.
[formatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:[[NSTimeZone localTimeZone] secondsFromGMT]]];

NSDate *date = nil;
NSError *error = nil;

[formatter getObjectValue:&date
                         forString:dateString
                             range:NULL
                             error:&error];

Again, this is not technically correct to do, but it is OK to do for display purposes.

Why won't NSDateFormatter parse this date?

I don't understand why the weekday is there. It creates the possibility of an inconsistent date. What would you expect of "20130412 Tuesday"? (note for future readers: 20130412 is in fact a Friday) I checked http://userguide.icu-project.org/formatparse/datetime and could find no prohibition on adding the day of the week, but it seems like a bad idea to me.

However, the NSDateFormatter does not appear to be behaving correctly. I tested on iOS 6.1 simulator and on OS X 10.8.3, and got the same results on both platforms. I even expanded a bit, adding

id longResult;
NSError *error;
NSRange range = NSMakeRange(0, testDate.length);
if (![df getObjectValue:&longResult forString:testDate range:&range error:&error]) {
    NSLog(@"error: %@ reason:%@", error.localizedDescription, error.localizedFailureReason );
}

NSLog(@"result: %@", longResult);
NSLog(@"%@", NSStringFromRange(range));

below your code and producing

2013-04-10 16:45:27.921 date formatter fun ios[47350:c07] test: 20130412 Friday, result: 1999-12-31 07:00:00 +0000
2013-04-10 16:45:27.922 date formatter fun ios[47350:c07] result: 1999-12-31 07:00:00 +0000
2013-04-10 16:45:27.922 date formatter fun ios[47350:c07] {0, 15}

It's attempting to parse, returning a YES (successful parse), yet putting the wrong answer into the result.

NSDateFormatter seems to have the wrong month

Try this

    [UTCDateFormat setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss'Z'"];

DD is the "Day of the year" not the "Day of a month". A great source for looking up NSDateFormatter formats is this table

NSDateFormatter dateFromString and iPhone in 24 Hour Format Confusion

Not sure if you still need it, but I've had a similar problem which got solved by setting the locale for the date formatter. That is, if you want to force it to 12-hour mode, regardless of the user's 24/12 hour mode setting, you should set the locale to en_US_POSIX.

Nsdateformatter + Timezone issue

Your solution to this problem is to change the locale to en_GB and the date formatter will be able to parse your date string properly.

Here is the explanation from the Apple developer bug reporting team in reply to radar #9944011:

This is an intentional change in iOS 5. The issue is this: With the short formats as specified by z (=zzz) or v (=vvv), there can be a lot of ambiguity. For example, "ET" for Eastern Time" could apply to different time zones in many different regions. To improve formatting and parsing reliability, the short forms are only used in a locale if the "cu" (commonly used) flag is set for the locale. Otherwise, only the long forms are used (for both formatting and parsing). This is a change in open-source CLDR 2.0 / ICU 4.8, which is the basis for the ICU in iOS 5, which in turn is the basis of NSDateFormatter behavior.

For the "en" locale (= "en_US"), the cu flag is set for metazones such as Alaska, America_Central, America_Eastern, America_Mountain, America_Pacific, Atlantic, Hawaii_Aleutian, and GMT. It is not set for Europe_Central.

However, for the "en_GB" locale, the cu flag is set for Europe_Central.

So, a formatter set for short timezone style "z" or "zzz" and locale "en" or "en_US" will not parse "CEST" or "CET", but if the locale is instead set to "en_GB" it will parse those. The "GMT" style will be parsed by all.

If the formatter is set for the long timezone style "zzzz", and the locale is any of "en", "en_US", or "en_GB", then any of the following will be parsed, because they are unambiguous:

"Pacific Daylight Time" "Central European Summer Time" "Central European Time"

struggling with NSDateFormatter in swift

I finally got it, the problem was in the line:

dateFormatter.locale = NSLocale.currentLocale()

in which I set the currentLocale, in the moment I fixed to a specific locale instead of the default (in iPhone and mac apparently are not the same, so for each one there is a different value).
changing the line to:

dateFormatter.locale = NSLocale(localeIdentifier: "en_US_POSIX")

solved the problem, now the extension is working as expected.

---

Related Topics