4 ms·

> You can use datetime libraries that are widely available to localize timestamps as needed in whatever way is required locally. But timestamps should get store

> 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
      Well, not really. :) Timezones are the whole area that has the same time. So "Europe/Berlin" and "Europe/Rome" right now can be used in user-facing help texts to make the timezone understandable, but those cities might not be in the help text in the future. That's because: "Each time zone is defined by a standard offset from Coordinated Universal Time (UTC)." (https://en.m.wikipedia.org/wiki/Time_zone https://en.m.wikipedia.org/wiki/Time_zone) So the offset is the timezone. That's why I stand with my original point: if you want to support "clock on the wall" future dates, a geolocation is needed. And given that Germany was two countries in the recent past and Frankfurt and Berlin were in different countries, I wouldn't solve this by picking a city from the help text that's currently closest to the timezone, but instead use the actual geolocation of the event. P.s. All this is, of course, for 99.99% of the cases a complete overkill, and as said, I haven't had issues in using unix epoch for all dates. But just wanted to say that timestamps aren't as simple as I felt was suggested in the first comment.

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
    Well, not really. :) Timezones are the whole area that has the same time. So "Europe/Berlin" and "Europe/Rome" right now can be used in user-facing help texts to make the timezone understandable, but those cities might not be in the help text in the future. That's because: "Each time zone is defined by a standard offset from Coordinated Universal Time (UTC)." (https://en.m.wikipedia.org/wiki/Time_zone https://en.m.wikipedia.org/wiki/Time_zone) So the offset is the timezone. That's why I stand with my original point: if you want to support "clock on the wall" future dates, a geolocation is needed. And given that Germany was two countries in the recent past and Frankfurt and Berlin were in different countries, I wouldn't solve this by picking a city from the help text that's currently closest to the timezone, but instead use the actual geolocation of the event. P.s. All this is, of course, for 99.99% of the cases a complete overkill, and as said, I haven't had issues in using unix epoch for all dates. But just wanted to say that timestamps aren't as simple as I felt was suggested in the first comment.