Challenges With Ancient Dates in Apple SDKs
Foundation’s date-handling code has an effective lower bound around January 1, 4713 BC on the Julian calendar. You can create a
Datevalue representing an instant in time below that limit, but manyCalendarmethods will return unexpected values when you try to do anything with it.[…]
And
NSDatePickerdoes okay with BC dates. […]UIDatePicker, however, simply cuts off at AD 1.[…]
When formatting or parsing dates, there is no way to override the built-in era symbols (like “BC” and “AD”) or, in locales where multiple conventions are in use, to choose among them.
[…]
(For going to and from strings, the older
DateFormattertype does have such a property [for the Julian to Gregorian transition] defined, but it wasn’t carried forward into the newerDate.FormatStyleAPI, and it obviously doesn’t affectDateComponentsconversions.)
Previously:
- Storing Times for Human Events
- ISO8601DateFormatter and Fractional Seconds
- Leap Year Bugs
- Falsehoods About Time and CSVs
1 Comment RSS · Twitter · Mastodon
I have experienced similar issues, the worst being that I discovered changes in ancient date behaviour from macOS prior to 26.0 versus post, then further changes in 26.3, all of which resulted in bug reports from my app users depending on which macOS versions they were running. I had to implement some fundamental custom overrides to obtain consistent & correct behaviour of my app across all OS versions.
