3 ms·
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 cloc
by 8n4vidtmkvmk 2y ago
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.
- kuon 2y agoRFC 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://news.ycombinator.com/item?id=37339535 https://news.ycombinator.com/item?id=37339535 https://www.mooncratertycho.com/the-12-lunar-calendars-still-in-use-around-the-world/ https://www.mooncratertycho.com/the-12-lunar-calendars-still...
- 8n4vidtmkvmk 2y agoNice! https://i.imgur.com/vsC2Wyd.png 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.