| ▲ | danlitt 3 days ago |
| Would you agree then that local time should never be used to represent an instant of time, such as the time of a physical event? If so then the use cases for local time seem very very narrow, in particular the top comment in this thread (adding 1 day and 3 hours to a timestamp) should never use local time, since the result is not well-defined. |
|
| ▲ | akio 3 days ago | parent | next [-] |
| No. Local time should nearly always be used to represent the time of future physical events (along side a geographical location, such as an address). Your method of using a named time zone like “Europe/London” is generally wrong for future physical events, and leads to bugs if and when the actual physical location of the event changes named time zones (which does happen). If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not a named time zone. Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow. Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed. Physical future events are not a fixed instant on the universal timeline, they are a local time + a location. |
| |
| ▲ | progval 3 days ago | parent | next [-] | | > Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow. Not that in invalidates your overall point, but in that case the TZ database would create a new timezone (eg. named Europe/Dnipro) to reflect that from 1996 to 2030 it was UTC+2/UTC+3 (with EU DST rules); then switched to UTC+3 only. This reflects that there is a place whose rules changed on 2030. Places don't move to an other existing timezone because that would prevent reasoning about past datetimes. | | |
| ▲ | akio 3 days ago | parent | next [-] | | Good point. As you mention, that doesn’t matter in this case, as even if a new named time zone is added, the stored named time zone would’ve been written before Europe/Dnipro was created (in case anyone’s wondering why this doesn’t invalidate the point). | |
| ▲ | 0cf8612b2e1e 2 days ago | parent | prev [-] | | How do the time databases handle location renaming (eg in 2030, Dnipro becomes Putinville? | | |
| |
| ▲ | danlitt 2 days ago | parent | prev [-] | | > Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow. I think in this case Europe/Kyiv would actually change its UTC offset to match Europe/Moscow, which I'm pretty sure the TZ database would handle just fine. > Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed. I think a sentence like this should jump out in big red letters. At face value it is not meaningful - how can our meeting time have not changed if the exact instant it occurs has changed? If you chase this thought to its logical conclusion then it is not as obvious as you suggest. For instance, the number of hours between now and your proposed meeting has changed. Two meetings that happened to be simultaneous before now are no longer simultaneous because their relative UTC offsets changed. Is that a bug? What if your future physical event is the arrival of a train? The choice in front of you is to pick a completely precise specification on which everyone agrees (the "instant of time") with an incomplete specification which you admit yourself may change in the future. My vote is to at least encode something unambiguous, and then to adjust it if my vague notion (local time) changes. | | |
| ▲ | 1718627440 2 days ago | parent | next [-] | | > how can our meeting time have not changed if the exact instant it occurs has changed? Because human time is not a numeric offset, but a name of relevant points. > The choice in front of you is to pick a completely precise specification on which everyone agrees (the "instant of time") with an incomplete specification which you admit yourself may change in the future. My vote is to at least encode something unambiguous The incomplete ambiguous specification is the one everyone agrees to, programmers just don't like them. | |
| ▲ | akio 2 days ago | parent | prev [-] | | > I think in this case Europe/Kyiv would actually change its UTC offset to match Europe/Moscow, which I'm pretty sure the TZ database would handle just fine. Another user has already responded to the rest of your comment, so I’ll just respond to this. In the Ukraine scenario Russia does not control Kyiv, so no, Europe/Kyiv would not change its offset. |
|
|
|
| ▲ | dvdkon 3 days ago | parent | prev | next [-] |
| Yes, local datetimes shouldn't be used to represent instants. But I think you can still add days or hours to them. Don't think of the hours here as units of time, just as parts of the datetime. It's the same as with months: A month doesn't have a defined length in seconds, but you can still add X months to a date without worry, because you aren't using them as units of time, but as "units of calendar". Duration vs Period in java.time parlance. |
|
| ▲ | fauigerzigerk 3 days ago | parent | prev | next [-] |
| We just have to use the correct representation for the use case at hand. All I'm saying is that not all date/times can be stored as an instant in time. An appointment/event reminder is a case in point. |
|
| ▲ | yencabulator a day ago | parent | prev [-] |
| Consider an old school wrist watch, before "smart" everything. Consider a wall mounted clock. Both display time, neither has a clue what time zone it is in. Calling those use cases "narrow" seems utterly silly; they've been the primary mechanism by which people interacted with time. Civil time is, by definition, messy. Politics can influence what I mean when I say "the shop opens at 8am". |
