3 ms·

Is this article arguing that a timestamp should include space ? I get that timestamp can be display differently depending on the space (i.e. TZ and locale). Bu

by llsf 2y ago

Is this article arguing that a timestamp should include space ? I get that timestamp can be display differently depending on the space (i.e. TZ and locale). But does it mean that we need to add the space component to a timestamp ? Feels like 2 distinct things. Sure, when I record an event, I might not only want to record "when" it happened, and "where". But the "where" does not change or impact the "when", and vice-versa. Those feel 2 distinct properties to me, and I might want to store them separately. Maybe I am missing something.

Macha 2y ago
For past timestamps, arguably a UTC record of when it happened is sufficient as converting it for display in a specific timezone is a fixed, and no longer mutable transformation. For a future looking time, it's not sufficient, because e.g. DST rules might change, timezones might change (and there's usually at least several occurrences a year of some timezone or DST rule changing somewhere in the world). If you have a reservation for the concert hall from 6pm next September, you don't want to show up there with the previous show still occupying the venue just because your government abolished DST in the year in between.
- llsf 2y ago
  Perfect explanation. I did not thought about future events and changing TZ rules (which happen obviously depending on the country/government). Thanks!
lxgr 2y ago
Kind of, but space in the social sense of "set of places and people agreeing on what is local time", not the physical one. We need to record that whenever we want to talk to people about time and schedule things for them, just like we need to record their language and regional format preferences. In other words, you might not need that level of metadata for a physical simulation, but you'll definitely need it for a calendar app. For everything in between, it depends, and the safest bet is accordingly to just do it, if you can.
crote 2y ago
A complete timestamp should include a timezone, and a timezone is best defined with a geographic location. Example: you want to schedule events in Madrid, Spain and Warsaw, Poland. Currently they both use the CE(S)T timezone, but the EU is looking into abolishing summer time - which would lead to countries adopting their own timezones. At the moment "Europe/Madrid" and "Europe/Warsaw" are identical to CET/CEST, but that hasn't always been the case in the past and obviously there's no guarantee it'll always be the case in the future. If you stored those events as CE(S)T, what are you going to do when summer time gets abolished and Madrid ends up at +1:00 year-round but Warsaw at +3:00 year-round?

by llsf 2y ago

Macha 2y ago

For past timestamps, arguably a UTC record of when it happened is sufficient as converting it for display in a specific timezone is a fixed, and no longer mutable transformation. For a future looking time, it's not sufficient, because e.g. DST rules might change, timezones might change (and there's usually at least several occurrences a year of some timezone or DST rule changing somewhere in the world). If you have a reservation for the concert hall from 6pm next September, you don't want to show up there with the previous show still occupying the venue just because your government abolished DST in the year in between.

llsf 2y ago
Perfect explanation. I did not thought about future events and changing TZ rules (which happen obviously depending on the country/government). Thanks!

lxgr 2y ago

Kind of, but space in the social sense of "set of places and people agreeing on what is local time", not the physical one. We need to record that whenever we want to talk to people about time and schedule things for them, just like we need to record their language and regional format preferences. In other words, you might not need that level of metadata for a physical simulation, but you'll definitely need it for a calendar app. For everything in between, it depends, and the safest bet is accordingly to just do it, if you can.

crote 2y ago

A complete timestamp should include a timezone, and a timezone is best defined with a geographic location. Example: you want to schedule events in Madrid, Spain and Warsaw, Poland. Currently they both use the CE(S)T timezone, but the EU is looking into abolishing summer time - which would lead to countries adopting their own timezones. At the moment "Europe/Madrid" and "Europe/Warsaw" are identical to CET/CEST, but that hasn't always been the case in the past and obviously there's no guarantee it'll always be the case in the future. If you stored those events as CE(S)T, what are you going to do when summer time gets abolished and Madrid ends up at +1:00 year-round but Warsaw at +3:00 year-round?