4 ms·

Most of the time RFC is the way to go as ISO specs are not available for free and many open source implementation are actually not fully open source compliant b

by kuon 3y ago

Most of the time RFC is the way to go as ISO specs are not available for free and many open source implementation are actually not fully open source compliant because based on drafts. It's also a really big effort for open source devs. Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that. In Europe and USA the timezones are quite stable, so we might not be confronted to this, but in many places timzones change quite often, and storing an offset is not stable. Having "june 5 2026, 13h30 wall clock, paris" is what most people will mean, and it might be UTC+2 or UTC+1 depending if EU finally decide on what to do with DST. And finally, if you write an API with times in the past, just use POSIX timestamps in seconds, ms, us or ns.

toast0 3y ago
> Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that. iCalendar is an RFC standard for this. [1] Note that some times have two representations and some times are not representable in this format when there's a time change due to DST. iCal also does not contemplate a location being reassigned to a different time zone, an issue discussed elsewhere in this thread. Of course, properly formatted iCal files also include data for all of the referenced timezones. Which makes it cumbersome if you just wanted to output a single datetime. [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
WorldMaker 3y ago
There is a draft standard called IXDTF that extends RFC 3339 to include the IANA timezone names in square brackets: 2026-06-05T13:30+0200[Europe/Paris] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-09.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...
- kuon 3y ago
  That is very promising! But as timezones change, we need place names, not timezone names.
  - WorldMaker 3y ago
    The IANA timezone database uses place names (mostly city names) for that reason. "Europe/Paris" in that example I gave is very not "Central European Summer Time" (or "CEST"), Paris' current timezone name. The IANA's timezone database tracks key cities and especially ones with historically unique timezones or that have shifted between timezones. It certainly doesn't list all places, but it lists most of the key ones that have carried weight on timezones, and is about the best database a lot of internet nerds have managed to accumulate of a lot of the complexity of current (and historic) timezones by roughly place name.

by kuon 3y ago

toast0 3y ago

> Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that. iCalendar is an RFC standard for this. [1] Note that some times have two representations and some times are not representable in this format when there's a time change due to DST. iCal also does not contemplate a location being reassigned to a different time zone, an issue discussed elsewhere in this thread. Of course, properly formatted iCal files also include data for all of the referenced timezones. Which makes it cumbersome if you just wanted to output a single datetime. [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...

WorldMaker 3y ago

There is a draft standard called IXDTF that extends RFC 3339 to include the IANA timezone names in square brackets: 2026-06-05T13:30+0200[Europe/Paris] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-09.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...

kuon 3y ago
That is very promising! But as timezones change, we need place names, not timezone names.
- WorldMaker 3y ago
  The IANA timezone database uses place names (mostly city names) for that reason. "Europe/Paris" in that example I gave is very not "Central European Summer Time" (or "CEST"), Paris' current timezone name. The IANA's timezone database tracks key cities and especially ones with historically unique timezones or that have shifted between timezones. It certainly doesn't list all places, but it lists most of the key ones that have carried weight on timezones, and is about the best database a lot of internet nerds have managed to accumulate of a lot of the complexity of current (and historic) timezones by roughly place name.