[josecastillo]

I've encountered just about every item on this list working on my Apple Watch complication, Better Day[1], which supports 11 calendar systems in 21 languages. The funny thing is, the last item on this list — always use ICU through the NSCalendar API — is the exact conclusion I arrived at, and one that I preach to anyone who will listen.

Especially with modern Swift syntax, complex questions like "what's the current day of the year" end up having simple, almost poetic answers like "calendar.ordinality(of: .day, in: .year, for: date)". And you can trust that they are correct for every calendar and every locale. Usually. [2]

[1] https://itunes.apple.com/us/app/better-day-a-complication/id...

[2] https://www.joeycastillo.com/notes/2016/09/18/of-crescent-mo...

[tewt]

I only skimmed your article, but are you sure that's right? There must have been at least several date adjustments before your app was release yet the system time maintained the correct date. Presumably it'll correct afterwards, invalidating the date offset.

[josecastillo]

The thing to keep in mind is that before the sighting, the months are pre-calculated for when the first crescent moon should rise over Mecca. So a change only affects the single month where the observation differed. For example, if you're expecting to see the first crescent moons on October 10, November 9 and December 8, but you didn't see the first one until October 11, that doesn't push the moon sightings out for the rest of the year. It just means that the month you thought would end on October 9 will have an extra day, and the month you thought would start on October 10 will start a day later (and as a result will be a day shorter).

Future months are still totally fine; the date offset is just a temporary fix that the user remembers to turn on when the announcement is made, and to turn off at the end of the month.