4 ms·

IMHO, ISO 8601 as a standard is way too broad and unspecific. ISO 8601 is way too messy. Telling somebody that they need to parse an ISO 8601 date time is not e

IMHO, ISO 8601 as a standard is way too broad and unspecific. ISO 8601 is way too messy. Telling somebody that they need to parse an ISO 8601 date time is not enough information to do the job. Which variant is it? Does it include the time part. IMHO allowing the full range of ISO 8601 dates and times in a data format is usually a mistake. You want to be more specific. There's a need for a standard that locks down the commonly used variants of it and gets rid of all the ambiguity. For me, timestamps following this pattern 'YYYY-MM-DDThh:mm:ss.xxxxxZ' is all that I use and all my APIs will accept/produce. It's nice that other legacy systems are available that don't normalize their timestamps to UTC for whatever reason, that consider seconds and fractions of a second optional, etc. But for unambiguous timestamps, all I want is this. It's fairly easy to write a parser for it. A simple regular expression will do the job. Of course add unit tests. Technically the Z is redundant information if we can all agree to normalize to UTC. Which IMHO we should. In the same way the T part and separators are redundant too. But they are nice for human readability. You can use datetime libraries that are widely available to localize timestamps as needed in whatever way is required locally. But timestamps should get stored and transmitted in a normalized and 100% unambiguous way. It's only when you get into supporting all the pointless and highly ambiguous but valid variants of ISO 8601 that parsing becomes a problem. There's actually no such thing as a parser that can parse all valid variants with no knowledge of which variant is being used. There are lots of libraries with complex APIs that support some or all of the major and minor variants of course. But not with just one function called parse(). I think the main challenge with ISO 8601 is that it never called out this variant as a separate thing that you should be using. This really should be its own standard. And not using that would be a mistake. ISO 8601 is what happens when you do design by committee.

ttiurani 1y ago
> You can use datetime libraries that are widely available to localize timestamps as needed in whatever way is required locally. But timestamps should get stored and transmitted in a normalized and 100% unambiguous way. If by "timestamp" you mean past dates and deterministic future dates, then agreed. (Although I prefer unix epoch in ms for those, to be able to use integers and skip string parsing steps completely.) But if your unlucky enough to need to handle future dates, especially "clock on the wall" ("let's meet in Frankfurt on July 26th 2029 at 1pm"), then you just can't know the timezone. The reasons can be many political ones, but especially in this case there's a high probability that EU will remove daylight saving time by then. So in those cases, if you want to be correct, you'd need to include the geolocation in the stored timestamp.
- jillesvangurp 1y ago
  > Frankfurt on July 26th 2029 at 1pm That's a localized date and time. And it shouldn't be what you store but what you present based on the user's preferences. The same calendar event would be completely different in the calendar of a tourist visiting Frankfurt. And calendar invites of course can have multiple participants that each want their date times localized to their time zone and locale. So the best way to do that is to store the time zone in a 100% normalized, unambiguous way that is then transformed into whatever matches the user's preferences as part of the presentation logic. In the same way, place names are localized. The French would spell Frankfurt as Francfort, for example. Location should be a separate field. And it implies nothing about the locale that should be used for presenting the timestamp or the timezone that should be used. Because Frankfurt is a rather international town and some might prefer MM DD YY instead of DD MM YYYY. Not to mention the use of am/pm vs. 24 hour time. And of course it has a big airport that people use to travel to pretty much all time zones on the planet. Hard coding all that in a timestamp is a mistake. Because now you need needlessly complex parsing logic and transformation logic to fix that mistake. Which is what this article is about.
  - ttiurani 1y ago
    > That's a localized date and time. Note that I'm not arguing against storing the numeric part in a consistent format, of course you should. My point is that right mow in 2025 you don't know the timezone. E.g. if you write that as the zones are now, it would be "2029-07-26T11:00:00.000Z", but if the timezones change, then when a person is looking at their calendar in 2029, they will be an hour early or late to the meeting. So it's not about presentation of the timestamp, it's that the timestamp does not match what the user meant. > In the same way, place names are localized. I beg to disagree. All spellings refer to the same phyysical place, but you can't guarantee my example timestamp description and a simple ISO time representation without a geolocation will refer to the same singular point in time.
    - skrebbel 1y ago
      I agree with the gist of your comment but I think you’re using the wrong words. A time zone, as the name implies, is a zone, a place. The most common way to indicate a timezone is a continent+city combo that is both politically and geographically close, so it’s unlikely to change. Therefore, I very much know the timezone of Frankfurt, both today and in the reasonably close future, namely “Europe/Berlin”. You’re talking about the timezone offset. You’re right, don’t store that for future local dates. Store the timezone. (Or just the exact location, but then you need a way to map location -> offset if you ever want to do time math on it, and the IANA Continent/City format strikes a nice pragmatic balance there)

ttiurani 1y ago

> You can use datetime libraries that are widely available to localize timestamps as needed in whatever way is required locally. But timestamps should get stored and transmitted in a normalized and 100% unambiguous way. If by "timestamp" you mean past dates and deterministic future dates, then agreed. (Although I prefer unix epoch in ms for those, to be able to use integers and skip string parsing steps completely.) But if your unlucky enough to need to handle future dates, especially "clock on the wall" ("let's meet in Frankfurt on July 26th 2029 at 1pm"), then you just can't know the timezone. The reasons can be many political ones, but especially in this case there's a high probability that EU will remove daylight saving time by then. So in those cases, if you want to be correct, you'd need to include the geolocation in the stored timestamp.

jillesvangurp 1y ago
> Frankfurt on July 26th 2029 at 1pm That's a localized date and time. And it shouldn't be what you store but what you present based on the user's preferences. The same calendar event would be completely different in the calendar of a tourist visiting Frankfurt. And calendar invites of course can have multiple participants that each want their date times localized to their time zone and locale. So the best way to do that is to store the time zone in a 100% normalized, unambiguous way that is then transformed into whatever matches the user's preferences as part of the presentation logic. In the same way, place names are localized. The French would spell Frankfurt as Francfort, for example. Location should be a separate field. And it implies nothing about the locale that should be used for presenting the timestamp or the timezone that should be used. Because Frankfurt is a rather international town and some might prefer MM DD YY instead of DD MM YYYY. Not to mention the use of am/pm vs. 24 hour time. And of course it has a big airport that people use to travel to pretty much all time zones on the planet. Hard coding all that in a timestamp is a mistake. Because now you need needlessly complex parsing logic and transformation logic to fix that mistake. Which is what this article is about.
- ttiurani 1y ago
  > That's a localized date and time. Note that I'm not arguing against storing the numeric part in a consistent format, of course you should. My point is that right mow in 2025 you don't know the timezone. E.g. if you write that as the zones are now, it would be "2029-07-26T11:00:00.000Z", but if the timezones change, then when a person is looking at their calendar in 2029, they will be an hour early or late to the meeting. So it's not about presentation of the timestamp, it's that the timestamp does not match what the user meant. > In the same way, place names are localized. I beg to disagree. All spellings refer to the same phyysical place, but you can't guarantee my example timestamp description and a simple ISO time representation without a geolocation will refer to the same singular point in time.
  - skrebbel 1y ago
    I agree with the gist of your comment but I think you’re using the wrong words. A time zone, as the name implies, is a zone, a place. The most common way to indicate a timezone is a continent+city combo that is both politically and geographically close, so it’s unlikely to change. Therefore, I very much know the timezone of Frankfurt, both today and in the reasonably close future, namely “Europe/Berlin”. You’re talking about the timezone offset. You’re right, don’t store that for future local dates. Store the timezone. (Or just the exact location, but then you need a way to map location -> offset if you ever want to do time math on it, and the IANA Continent/City format strikes a nice pragmatic balance there)