Comment by kuon
8 months ago
ISO is non free garbage which is not helping the software ecosystem. Take ISO 8601, it is overly complicated, not implemented correctly most of the time as maintainers used a free draft and it does not actually solve anything properly. (For example you cannot represent wall clock which is a problem for dates in the future as time zone changes).
I also worked with mp4 in the past only to realize that the ISO was not enough as Apple had some changes in their stack.
> For example you cannot represent wall clock which is a problem for dates in the future as time zone changes
While I understand this particular frustration, in my book it is a feature. The critique usually devolves into hypothetical scenarios, e.g. changes to DST. "I want to be able to specify 14:00 in four years in Absurdistan local time, whatever that is in relation to UTC, but cannot!" is a common critique of ISO 8601. However, if you go a little bit further with hypotheticals, Absurdistan might add some overseas territories, might join some alliance and change timezone/DST, etc.
When you think about the problem statement, definition of "local time" itself may change, therefore it is impossible to specify "local time" in the future without *exhaustively* defining all possible changes.
So you either define number of atomic ticks (TAI) in the future and resolve local time at the time of use or specify some static time and resolve it to local time at the time of use.
Are there any alternatives to iso8601? My only beef with it is that there seems to be more than 1 way to represent a few things. Didn't know about the wall clock issue.
I wonder if the new JS temporal API handles that.. they went pretty deep.
RFC 3339 should be preferred to iso, but it does not solve the wall clock issue. In a calendar application I worked on, we use city name and lat/lng + "naive" timestamp (yyyy-mm-dd hh:mm or moon based date or other specialties like Japanese year depending on the locale). And we "resolve" to UTC + offset when the date is close.
https://www.mooncratertycho.com/the-12-lunar-calendars-still...
Nice! https://i.imgur.com/vsC2Wyd.png
See even RFC 3339 seems unnecessarily lax. You can use _ or lowercase t or space as the date and time separator? Why? Just pick one instead of complicating all the parsers.
The intersection of the two specs seems pretty good though.