On Feb 26, 2019, at 10:17 AM, Tony Finch <dot@dotat.at> wrote:
Guy Harris <guy@alum.mit.edu> wrote:
And I'm not even convinced that users want to care about tzdb regions; those regions don't completely correspond to, for example, what people call "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't correspond to the America/Denver tzdb region - Arizona is in the "Mountain" time zone, but it hasn't done standard/summar time switching since 1968, unlike other parts of that time zone.
What I suspect users want is to have clock time work appropriately for their location; if doing so doesn't involve knowing or caring about the details of the tzdb, so much the better.
Up to a point...
A common cause of significant confusion is when people are trying to organize meetings between people in multiple time zones. I think the confusion is due to poor calendaring data models which make it difficult to provide a user interface that illustrates what is going on.
... None of which appears to require that the *end users* - including the meeting organizer(s) - know or care about the details of the tzdb. They may need to know that scheduling the meeting for thus-and-such a time in London means scheduling it for 03:00 at some other location, so, if they schedule for that time, somebody's going to have to wake up early or go to sleep late, but that's what the software would do.