{"id":51495,"date":"2026-04-07T18:53:27","date_gmt":"2026-04-07T22:53:27","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=51495"},"modified":"2026-04-07T18:53:27","modified_gmt":"2026-04-07T22:53:27","slug":"challenges-with-ancient-dates-in-apple-sdks","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/04\/07\/challenges-with-ancient-dates-in-apple-sdks\/","title":{"rendered":"Challenges With Ancient Dates in Apple SDKs"},"content":{"rendered":"

Aaron Trickey<\/a>:<\/p>\n

\n

Foundation’s date-handling code has an effective lower bound around January 1, 4713 BC on the Julian calendar. You can create a Date<\/code> value representing an instant in time below that limit, but many Calendar<\/code> methods will return unexpected values when you try to do anything with it.<\/p>\n

[…]<\/p>\n

And NSDatePicker<\/code> does okay with BC dates. […] UIDatePicker<\/code>, however, simply cuts off at AD 1.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

(For going to and from strings, the older DateFormatter<\/code> type does have such a property [for the Julian to Gregorian transition] defined, but it wasn’t carried forward into the newer Date.FormatStyle<\/code> API, and it obviously doesn’t affect DateComponents<\/code> conversions.)<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n