What is the best way to deal with the NSDateFormatter locale "feature"?

Asked 7/7, 2011 at 15:30 Answered 25/12, 2017 at 14:37

Solved ios objective-c iphone locale nsdateformatter

174

It seems that NSDateFormatter has a "feature" that bites you unexpectedly: If you do a simple "fixed" format operation such as:

NSDateFormatter* fmt = [[NSDateFormatter alloc] init];
[fmt setDateFormat:@"yyyyMMddHHmmss"];
NSString* dateStr = [fmt stringFromDate:someDate];
[fmt release];

Then it works fine in the US and most locales UNTIL ... someone with their phone set to a 24-hour region sets the 12/24 hour switch in settings to 12. Then the above starts tacking "AM" or "PM" onto the end of the resulting string.

(See, eg, NSDateFormatter, am I doing something wrong or is this a bug?)

(And see https://developer.apple.com/library/content/qa/qa1480/_index.html)

Apparently Apple has declared this to be "BAD" -- Broken As Designed, and they aren't going to fix it.

The circumvention is apparently to set the locale of the date formatter for a specific region, generally the US, but this is a bit messy:

NSLocale *loc = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US"];
[df setLocale: loc];
[loc release];

Not too bad in onesies-twosies, but I'm dealing with about ten different apps, and the first one I look at has 43 instances of this scenario.

So any clever ideas for a macro/overridden class/whatever to minimize the effort to change everything, without making the code to obscure? (My first instinct is to override NSDateFormatter with a version that would set the locale in the init method. Requires changing two lines -- the alloc/init line and the added import.)

##Added

This is what I've come up with so far -- seems to work in all scenarios:

@implementation BNSDateFormatter

-(id)init {
static NSLocale* en_US_POSIX = nil;
NSDateFormatter* me = [super init];
if (en_US_POSIX == nil) {
    en_US_POSIX = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
}
[me setLocale:en_US_POSIX];
return me;
}

@end

##Update Re OMZ's proposal, here is what I'm finding --

Here is the category version -- h file:

#import <Foundation/Foundation.h>


@interface NSDateFormatter (Locale)
- (id)initWithSafeLocale;
@end

Category m file:

#import "NSDateFormatter+Locale.h"


@implementation NSDateFormatter (Locale)

- (id)initWithSafeLocale {
static NSLocale* en_US_POSIX = nil;
self = [super init];
if (en_US_POSIX == nil) {
    en_US_POSIX = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
}
NSLog(@"Category's locale: %@ %@", en_US_POSIX.description, [en_US_POSIX localeIdentifier]);
[self setLocale:en_US_POSIX];
return self;    
}

@end

The code:

NSDateFormatter* fmt;
NSString* dateString;
NSDate* date1;
NSDate* date2;
NSDate* date3;
NSDate* date4;

fmt = [[NSDateFormatter alloc] initWithSafeLocale];
[fmt setDateFormat:@"yyyy-MM-dd HH:mm:ss"];
dateString = [fmt stringFromDate:[NSDate date]];
NSLog(@"dateString = %@", dateString);
date1 = [fmt dateFromString:@"2001-05-05 12:34:56"];
NSLog(@"date1 = %@", date1.description);
date2 = [fmt dateFromString:@"2001-05-05 22:34:56"];
NSLog(@"date2 = %@", date2.description);
date3 = [fmt dateFromString:@"2001-05-05 12:34:56PM"];  
NSLog(@"date3 = %@", date3.description);
date4 = [fmt dateFromString:@"2001-05-05 12:34:56 PM"]; 
NSLog(@"date4 = %@", date4.description);
[fmt release];

fmt = [[BNSDateFormatter alloc] init];
[fmt setDateFormat:@"yyyy-MM-dd HH:mm:ss"];
dateString = [fmt stringFromDate:[NSDate date]];
NSLog(@"dateString = %@", dateString);
date1 = [fmt dateFromString:@"2001-05-05 12:34:56"];
NSLog(@"date1 = %@", date1.description);
date2 = [fmt dateFromString:@"2001-05-05 22:34:56"];
NSLog(@"date2 = %@", date2.description);
date3 = [fmt dateFromString:@"2001-05-05 12:34:56PM"];  
NSLog(@"date3 = %@", date3.description);
date4 = [fmt dateFromString:@"2001-05-05 12:34:56 PM"]; 
NSLog(@"date4 = %@", date4.description);
[fmt release];

The result:

2011-07-11 17:44:43.243 DemoApp[160:307] Category's locale: <__NSCFLocale: 0x11a820> en_US_POSIX
2011-07-11 17:44:43.257 DemoApp[160:307] dateString = 2011-07-11 05:44:43 PM
2011-07-11 17:44:43.264 DemoApp[160:307] date1 = (null)
2011-07-11 17:44:43.272 DemoApp[160:307] date2 = (null)
2011-07-11 17:44:43.280 DemoApp[160:307] date3 = (null)
2011-07-11 17:44:43.298 DemoApp[160:307] date4 = 2001-05-05 05:34:56 PM +0000
2011-07-11 17:44:43.311 DemoApp[160:307] Extended class's locale: <__NSCFLocale: 0x11a820> en_US_POSIX
2011-07-11 17:44:43.336 DemoApp[160:307] dateString = 2011-07-11 17:44:43
2011-07-11 17:44:43.352 DemoApp[160:307] date1 = 2001-05-05 05:34:56 PM +0000
2011-07-11 17:44:43.369 DemoApp[160:307] date2 = 2001-05-06 03:34:56 AM +0000
2011-07-11 17:44:43.380 DemoApp[160:307] date3 = (null)
2011-07-11 17:44:43.392 DemoApp[160:307] date4 = (null)

The phone [make that an iPod Touch] is set to Great Britain, with the 12/24 switch set to 12. There's a clear difference in the two results, and I judge the category version to be wrong. Note that the log in the category version IS getting executed (and stops placed in the code are hit), so it's not simply a case of the code somehow not getting used.

##A curious observation

Modified the category implementation slightly:

#import "NSDateFormatter+Locale.h"

@implementation NSDateFormatter (Locale)

- (id)initWithSafeLocale {
static NSLocale* en_US_POSIX2 = nil;
self = [super init];
if (en_US_POSIX2 == nil) {
    en_US_POSIX2 = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
}
NSLog(@"Category's locale: %@ %@", en_US_POSIX2.description, [en_US_POSIX2 localeIdentifier]);
[self setLocale:en_US_POSIX2];
NSLog(@"Category's object: %@ and object's locale: %@ %@", self.description, self.locale.description, [self.locale localeIdentifier]);
return self;    
}

@end

Basically just changed the name of the static locale variable (in case there was some conflict with the static declared in the subclass) and added the extra NSLog. But look what that NSLog prints:

2011-07-15 16:35:24.322 DemoApp[214:307] Category's locale: <__NSCFLocale: 0x160550> en_US_POSIX
2011-07-15 16:35:24.338 DemoApp[214:307] Category's object: <NSDateFormatter: 0x160d90> and object's locale: <__NSCFLocale: 0x12be70> en_GB
2011-07-15 16:35:24.345 DemoApp[214:307] dateString = 2011-07-15 04:35:24 PM
2011-07-15 16:35:24.370 DemoApp[214:307] date1 = (null)
2011-07-15 16:35:24.378 DemoApp[214:307] date2 = (null)
2011-07-15 16:35:24.390 DemoApp[214:307] date3 = (null)
2011-07-15 16:35:24.404 DemoApp[214:307] date4 = 2001-05-05 05:34:56 PM +0000

As you can see, the setLocale simply didn't. The locale of the formatter is still en_GB. It appears that there is something "strange" about an init method in a category.

Sewel answered 7/7, 2011 at 15:30 Comment(9)

Moshe, I don't know why you chose to edit the title. "Feechur" is a legitimate term in the art (and had been for 30 years or so), meaning an aspect or feature of some software that is sufficiently ill-conceived to be considered a bug, even though the authors refuse to admit it. – Sewel 12/7, 2011 at 0:50

when converting a string to date, the string must exactly match the formatter description - this is a tangential issue to your locality one. – Knew 12/7, 2011 at 18:26

The various date strings are there to test the different possible configurations, correct and erroneous. I know that some of them are invalid, given the formatting string. – Sewel 12/7, 2011 at 18:30

have you experimented with different values of - (NSDateFormatterBehavior)formatterBehavior ? – Knew 12/7, 2011 at 18:40

Haven't experimented with it. The spec is contradictory on whether it can even be changed in iOS. The main description says "iOS Note: iOS supports only the 10.4+ behavior", while the NSDateFormatterBehavior section says both modes are available (but it may be only talking about the constants). – Sewel 12/7, 2011 at 19:56

it wouldn't surprise me if only the 10.4+ behavior is available – Knew 12/7, 2011 at 20:17

@HotLicks I am bit confused, Is this issue still persist in iOS 6? Or apple solved this..? – Datolite 9/5, 2013 at 3:29

@JohnsonMathew -- AFAIK, Apple declared their way to be "correct", so they won't change it. Unless they change their minds. – Sewel 9/5, 2013 at 10:57

is NSDateFormatter thread-safe to call this from multiple threads? – Auction 24/3, 2016 at 21:57

Duh!!

Sometimes you have an "Aha!!" moment, sometimes it's more of a "Duh!!" This is the latter. In the category for initWithSafeLocale the "super" init was coded as self = [super init];. This inits the SUPERCLASS of NSDateFormatter but does not init the NSDateFormatter object itself.

Apparently when this initialization is skipped, setLocale "bounces off", presumably because of some missing data structure in the object. Changing the init to self = [self init]; causes the NSDateFormatter initialization to occur, and setLocale is happy again.

Here is the "final" source for the category's .m:

#import "NSDateFormatter+Locale.h"

@implementation NSDateFormatter (Locale)

- (id)initWithSafeLocale {
    static NSLocale* en_US_POSIX = nil;
    self = [self init];
    if (en_US_POSIX == nil) {
        en_US_POSIX = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
    }
    [self setLocale:en_US_POSIX];
    return self;    
}

@end

Sewel answered 18/7, 2011 at 15:50 Comment(10)

what will be the date formatter for "NSString *dateStr = @"2014-04-05T04:00:00.000Z";" ? – Estivate 22/5, 2014 at 11:59

@Agent - Look it up: unicode.org/reports/tr35/tr35-31/… – Sewel 22/5, 2014 at 14:59

@Auction - Shouldn't your question be about NSDateFormatter? – Sewel 24/3, 2016 at 21:58

@HotLicks yes my bad. I meat NSDateFormatter. – Auction 24/3, 2016 at 22:0

@Auction - What does the spec say? – Sewel 24/3, 2016 at 22:2

@HotLicks I read the specs where it says its not but i'm confused so asking for clarity. I was wondering if we should use dispatch_once to init the NSLocale for thread safety. Sorry if the question is too basic. – Auction 24/3, 2016 at 22:10

@Auction - One could argue that a locking protocol such as dispatch_once should be used in the above code to assure that only one instance of NSLocale gets created. As a practical matter there's no problem created if more than one instance is created, due to simultaneous execution of the code, but it's harmless to add the synchronization. Has nothing to do with whether NSLocale itself is thread-safe, nor with NSDateFormatter (which is thread safe for iOS, if you read the spec). – Sewel 24/3, 2016 at 22:44

Oh ok thanks for the clarification @HotLicks. I checked the page developer.apple.com/library/ios/documentation/Cocoa/Conceptual/… and saw NSDateFormatter listed under thread unsafe classes which is why I thought it wasn't thread safe. – Auction 24/3, 2016 at 23:3

@Auction - Some flavors of the class for OSx are not safe, and the same is true for very old flavors under iOS. But regular iOS is fine. – Sewel 24/3, 2016 at 23:9

@hotLicks Does this solution supports the case if user have Buddhist calendar in device settings? – Responsion 16/5, 2017 at 13:30

Instead of subclassing, you could create an NSDateFormatter category with an additional initializer that takes care of assigning the locale and possibly also a format string, so you'd have a ready-to-use formatter right after initializing it.

@interface NSDateFormatter (LocaleAdditions)

- (id)initWithPOSIXLocaleAndFormat:(NSString *)formatString;

@end

@implementation NSDateFormatter (LocaleAdditions)

- (id)initWithPOSIXLocaleAndFormat:(NSString *)formatString {
    self = [super init];
    if (self) {
        NSLocale *locale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
        [self setLocale:locale];
        [locale release];
        [self setFormat:formatString];
    }
    return self;
}

@end

Then you could use NSDateFormatter anywhere in your code with just:

NSDateFormatter* fmt = [[NSDateFormatter alloc] initWithPOSIXLocaleAndFormat:@"yyyyMMddHHmmss"];

You might want to prefix your category method somehow to avoid name conflicts, just in case Apple decides to add such a method in a future version of the OS.

In case you're always using the same date format(s), you could also add category methods that return singleton instances with certain configurations (something like +sharedRFC3339DateFormatter). Be aware however that NSDateFormatter is not thread-safe and you have to use locks or @synchronized blocks when you're using the same instance from multiple threads.

Inexpressible answered 9/7, 2011 at 17:9 Comment(7)

Would having a static NSLocale (like in my suggestion) work in a category? – Sewel 9/7, 2011 at 18:33

Yes, that should also work in a category. I left it out to make the example simpler. – Inexpressible 10/7, 2011 at 6:42

Curiously, the category approach doesn't work. The category method is executed, and it's getting the exact same Locale as the other version (I execute them back to back, category version first). Just somehow the setLocale apparently doesn't "take". – Sewel 11/7, 2011 at 22:33

It would be interesting to find out why this approach doesn't work. If no one comes up with something better I'll award the bounty to the best explanation of this apparent bug. – Sewel 12/7, 2011 at 19:56

Well, I'm awarding the bounty to OMZ, since he's the only one that made an apparent effort on this. – Sewel 16/7, 2011 at 10:36

@Inexpressible thanks for the solution. Does this solution supports buddhist calendar from iphone settings? – Responsion 16/5, 2017 at 13:23

"As of iOS 7, NSDateFormatters and NSNumberFormatters are "thread safe"" – Smoking 6/11, 2018 at 10:17

May I suggest something totally different because to be honest all of this is somewhat running down a rabbit hole.

You should be using one NSDateFormatter with dateFormat set and locale forced to en_US_POSIX for receiving dates (from servers/APIs).

Then you should be using a different NSDateFormatter for the UI which you will set the timeStyle/dateStyle properties - this way you're not having an explicit dateFormat set by yourself, thus falsely assuming that format will be used.

This means UI is driven by user preferences (am/pm vs 24 hour, and date strings formatted correctly to user choice - from iOS settings), whereas dates that are "coming into" your app are always being "parsed" correctly to an NSDate for you to use.

Farver answered 10/3, 2015 at 11:26 Comment(3)

Sometimes this scheme works, sometimes not. One hazard is that your method may need to modify the date format of the formatter and, in doing so, alter the format set by the code that called you, when it was in the middle of date formatting operations. There are other scenarios where the timezone must be changed repeatedly. – Sewel 10/3, 2015 at 11:32

I don't know why changing timeZone value of the formatter would get in the way of this scheme, could you elaborate? Also to be clear you would abstain from changing the format. If you need to do so then this would happen on an "import" formatter, so a separate formatter. – Farver 10/3, 2015 at 11:43

Any time you're changing the state of a global object it's dangerous. Easy to forget that others are using it too. – Sewel 10/3, 2015 at 11:46

Here is the solution for that problem in the swift version. In swift we can use extension instead of category. So, Here I have created the extension for the DateFormatter and inside that initWithSafeLocale returns the DateFormatter with the relevant Locale, Here in our case that is en_US_POSIX, Apart from that also provided couple of date formation methods.

Swift 4

extension DateFormatter {

private static var dateFormatter = DateFormatter()

class func initWithSafeLocale(withDateFormat dateFormat: String? = nil) -> DateFormatter {

    dateFormatter = DateFormatter()

    var en_US_POSIX: Locale? = nil;

    if (en_US_POSIX == nil) {
        en_US_POSIX = Locale.init(identifier: "en_US_POSIX")
    }
    dateFormatter.locale = en_US_POSIX

    if dateFormat != nil, let format = dateFormat {
        dateFormatter.dateFormat = format
    }else{
        dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss"
    }
    return dateFormatter
}

// ------------------------------------------------------------------------------------------

class func getDateFromString(string: String, fromFormat dateFormat: String? = nil) -> Date? {

    if dateFormat != nil, let format = dateFormat {
        dateFormatter = DateFormatter.initWithSafeLocale(withDateFormat: format)
    }else{
        dateFormatter = DateFormatter.initWithSafeLocale()
    }
    guard let date = dateFormatter.date(from: string) else {
        return nil
    }
    return date
}

// ------------------------------------------------------------------------------------------

class func getStringFromDate(date: Date, fromDateFormat dateFormat: String? = nil)-> String {

    if dateFormat != nil, let format = dateFormat {
        dateFormatter = DateFormatter.initWithSafeLocale(withDateFormat: format)
    }else{
        dateFormatter = DateFormatter.initWithSafeLocale()
    }

    let string = dateFormatter.string(from: date)

    return string
}   }

usage description:

let date = DateFormatter.getDateFromString(string: "11-07-2001”, fromFormat: "dd-MM-yyyy")
print("custom date : \(date)")
let dateFormatter = DateFormatter.initWithSafeLocale(withDateFormat: "yyyy-MM-dd HH:mm:ss")
let dt = DateFormatter.getDateFromString(string: "2001-05-05 12:34:56")
print("base date = \(dt)")
dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss"
let dateString = dateFormatter.string(from: Date())
print("dateString = " + dateString)
let date1 = dateFormatter.date(from: "2001-05-05 12:34:56")
print("date1 = \(String(describing: date1))")
let date2 = dateFormatter.date(from: "2001-05-05 22:34:56")
print("date2 = \(String(describing: date2))")
let date3 = dateFormatter.date(from: "2001-05-05 12:34:56PM")
print("date3 = \(String(describing: date3))")
let date4 = dateFormatter.date(from: "2001-05-05 12:34:56 PM")
print("date4 = \(String(describing: date4))")

Advisory answered 25/12, 2017 at 14:37 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Duh!!

Recommended topics

Hot tags