By Hot Licks


2011-07-07 15:30:14 8 Comments

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 onsies-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

Bounty!

I'll award the bounty to the best (legitimate) suggestion/critique I see by mid-day Tuesday. [See below -- deadline extended.]

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.

Bounty update:

Since I haven't gotten any applicable replies yet I'll extend the bounty deadline for another day or two.

Bounty ends in 21 hours -- it'll go to whoever makes the most effort to help, even if the answer isn't really useful in my case.

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.

Final answer

See the accepted answer below.

5 comments

@Tech 2017-12-25 14:37:30

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))")
    

@Khurshid 2017-03-15 11:52:42

Try This one....

-(NSDate *)getDateInCurrentSystemTimeZone
{
    NSDate* sourceDate = [NSDate date];
    NSTimeZone* sourceTimeZone = [NSTimeZone timeZoneWithAbbreviation:@"GMT"];
    NSTimeZone* destinationTimeZone = [NSTimeZone systemTimeZone];

    NSInteger sourceGMTOffset = [sourceTimeZone secondsFromGMTForDate:sourceDate];
    NSInteger destinationGMTOffset = [destinationTimeZone secondsFromGMTForDate:sourceDate];
    NSTimeInterval interval = destinationGMTOffset - sourceGMTOffset;

    NSDate* destinationDate = [[NSDate alloc] initWithTimeInterval:interval sinceDate:sourceDate];
    return destinationDate;
}

@Hot Licks 2011-07-18 15:50:51

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

@Agent Chocks. 2014-05-22 11:59:55

what will be the date formatter for "NSString *dateStr = @"2014-04-05T04:00:00.000Z";" ?

@Hot Licks 2014-05-22 14:59:31

@tbag 2016-03-24 21:49:28

is NSLocale thread-safe to call this from multiple threads?

@Hot Licks 2016-03-24 21:58:32

@tbag - Shouldn't your question be about NSDateFormatter?

@tbag 2016-03-24 22:00:45

@HotLicks yes my bad. I meat NSDateFormatter.

@Hot Licks 2016-03-24 22:02:23

@tbag - What does the spec say?

@tbag 2016-03-24 22:10:20

@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.

@Hot Licks 2016-03-24 22:44:30

@tbag - 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).

@tbag 2016-03-24 23:03:21

Oh ok thanks for the clarification @HotLicks. I checked the page developer.apple.com/library/ios/documentation/Cocoa/Conceptu‌​al/… and saw NSDateFormatter listed under thread unsafe classes which is why I thought it wasn't thread safe.

@Hot Licks 2016-03-24 23:09:37

@tbag - 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.

@toxicsun 2017-05-16 13:30:10

@hotLicks Does this solution supports the case if user have Buddhist calendar in device settings?

@Daniel 2015-03-10 11:26:34

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.

@Hot Licks 2015-03-10 11:32:30

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.

@Daniel 2015-03-10 11:43:17

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.

@Hot Licks 2015-03-10 11:46:10

Any time you're changing the state of a global object it's dangerous. Easy to forget that others are using it too.

@omz 2011-07-09 17:09:01

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.

@Hot Licks 2011-07-09 18:33:22

Would having a static NSLocale (like in my suggestion) work in a category?

@omz 2011-07-10 06:42:38

Yes, that should also work in a category. I left it out to make the example simpler.

@Hot Licks 2011-07-11 22:33:25

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".

@Hot Licks 2011-07-12 19:56:36

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.

@Hot Licks 2011-07-16 10:36:21

Well, I'm awarding the bounty to OMZ, since he's the only one that made an apparent effort on this.

@toxicsun 2017-05-16 13:23:47

@omz thanks for the solution. Does this solution supports buddhist calendar from iphone settings?

@user1105951 2018-11-06 10:17:35

"As of iOS 7, NSDateFormatters and NSNumberFormatters are "thread safe""

Related Questions

Sponsored Content

17 Answered Questions

[SOLVED] What is the best way to unit test Objective-C code?

8 Answered Questions

[SOLVED] What does the "__block" keyword mean?

34 Answered Questions

[SOLVED] How to fix a locale setting warning from Perl?

  • 2010-03-23 12:27:18
  • xain
  • 419875 View
  • 485 Score
  • 34 Answer
  • Tags:   perl locale

14 Answered Questions

[SOLVED] What is a typedef enum in Objective-C?

4 Answered Questions

[SOLVED] NSDateFormatter Locale

1 Answered Questions

[SOLVED] Localization in NSDateFormatter

1 Answered Questions

[SOLVED] Localized NSDateFormatter

33 Answered Questions

2 Answered Questions

[SOLVED] NSDate format issue

Sponsored Content