Mac NSDateFormatter behavior change with respect to 24-hour time formats

Number:rdar://21105874 Date Originated:26-May-2015 01:46 PM
Status:Open Resolved:26-May-2015 8:45 PM
Product:OS X Product Version:10.10.4
Classification:Serious Bug Reproducible:Always
NSDateFormatter on the Mac used to respect format strings such as e.g.:


Yielding a 24-hour formatted time, even if the user's default locale is not overridden on the NSDateFormatter instance.

At some point recently (I think starting with 10.10.3), the behavior changed such that when the default locale is set, a literal format such as the one above MAY be used to rewrite the resulting string with 12-hour time.

This change in behavior is problematic and has caused a real-world bug in MarsEdit, my blog editor app. The documentation for NSDateFormatter makes a point of stating that setDateFormat: should be used for situations where a very specific format is required e.g. for internet dates. This is precisely the reason and context I'm using setDateFormat, and the change in behavior is causing dates formatted by my app for use in XML documents to be formatted incorrectly.

The documentation also hints that the behavior I'm now seeing on Mac could have been seen previously on iOS. Maybe it's just a new feature that Mac now allows users to override the 12/24 hour formatting default?

In any case it's confusing and unclear how a developer who wants to convert literally to 24-hour time, using a format string, should do so. It feels fragile to set an explicit locale (e.g. to en_US), but I guess that is the best workaround?

Steps to Reproduce:
1. Open System Preferences and change the locale to a region e.g. United Kingdom where 24-hour time is default.
2. Manualy uncheck the 24-hour time to switch to 12-hour time.
3. Run the attached Python script which runs NSDateFormatter through the paces of formatting the current date first with no explicit locale, and then with an explicit one.

Expected Results:

Actual Results:

10.10.4 (14E17e)



'' was successfully uploaded.


I was wrong that this behavior is new to recent updates to OS X. I confirmed the behavior at least occurred on 10.9.4 and possibly earlier.

I opened another bug, Radar #21115452 to reflect my wish that the documentation will be updated to better emphasize the need to set a locale on NSDateFormatter to obtain predictable string generation. This issue has been verified as resolved and can be closed.

Gist with the python script

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!