Re:XML is better than YAML
by wokkel on Thursday September 21, 2023 @02:51AM
(#37594043)
The main reason i avoid any typeless language is dates... how do i represent a date/time including a time zone has been badly reinvented so many times. A string type is never the way to go there in my opinion.
[ Parent
| on HN ]
Re:XML is better than YAML
by bradgessler on Thursday September 21, 2023 @02:55AM
(#37594065)
What’s the best representation you’ve seen for dates?
Re:XML is better than YAML
by stackedinserter on Thursday September 21, 2023 @08:01AM
(#37596362)
UNIX timestamp. Plus timezone string, in separate field/column, if it's important for the use case (like calendar events, etc).
Epoch time + GPS coordinates.
That's as unambiguous as you could possibly make it IMO.
Hasn't https://en.wikipedia.org/wiki/ISO_8601 basically won, at this point?
One of the classic lessons of the Falsehoods Programmers Believe about Time is that in general you can't correctly do better than simply storing the user's input (and the instant and place they entered it from) verbatim, unless you know something more about what they were entering. It's usually fine to store times in the past as a timestamp since the epoch plus a location, but the meaning of "2025-01-28 15:00 in Europe/London, for the purpose of a meeting that's being hosted there but is accessible by video call" is much more subject to change when e.g. countries change time zone. It's also not necessarily the same as "the absolute point in time 2025-01-28 15:00 assuming London's time zones stay as predicted since I entered this on 2023-09-21" or "2025-01-28 15:00 in Europe/London, for the purposes of a meeting that's being hosted in Lisbon but which I'm accessing by video call from London" (because then the Lisbon local time is the source of truth, not the London one, if Lisbon changes time zone).