Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

>If local time is qualified with where "local" is then it is identical to using a time with a locale, like Europe/London or whatever

We may not know the location when we write down a datetime. It could be "wherever I may be at the time".

Even if we do know the location, we cannot know for sure what point in time a future local time refers to because locations can change timezones.

>Even your example of alarms is not obvious. If you set a timer, or a daily alarm to wake up by, then yes. But if you set an alarm for some event, like sunrise for example, then you would need a zone.

That's absolutely right. We need to be able to store points in time and we need to be able to store local times relative to locations that are yet to be determined and relative to as yet unknown timezones. The two concepts cannot be merged.

View on HN

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.

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.

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.

> 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.

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).

How do the time databases handle location renaming (eg in 2030, Dnipro becomes Putinville?

Each record encodes optional FROM and TO fields: https://en.wikipedia.org/wiki/Tz_database

> 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.

> 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.

> 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.

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.

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".

Reply on news.ycombinator.com