[tz] tzdb timezone names/identifiers and links
guy at alum.mit.edu
Tue Feb 26 19:18:15 UTC 2019
On Feb 26, 2019, at 9:54 AM, Fred Gleason <fredg at paravelsystems.com> wrote:
> On Tue, 2019-02-26 at 01:48 -0800, Guy Harris wrote:
>> All they want is that the clock face on their smartwatch/clock on
>> their smartphone/clock in the bar at the top or bottom of their
>> screen display the correct current date and time, that their file
>> manager report the correct creation/modification date and time for
>> files, etc..
> Not always!
> For example, we make an embedded IoT product that allows up to six
> date/time displays to be shown simultaneously, each configurable to use
> a different time zone. In that particular use case, the 'determine my
> time zone automatically' method is not only irrelevant, but can be
> positively harmful.
There's a company that makes a handheld device that
1) uses the "determine my time zone automatically" method
2) offers a display that shows multiple date/time displays, each one configurable to a location.
That combination works Just Fine.
I'm not sure whether that display can include a "where I am" entry; it's not even reporting my location correctly, it insists on calling it "Cupertino".
(Yes, that's a spoiler; you can probably guess that the company in question is the same company whose time zone selector I've been giving as an example of the right way to do things. :-))
All the user who pops up World Clock on their iPhone wants is for those items to display the correct time and appropriate date indication ("Today", "Yesterday", or "Tomorrow", I suspect) - they really don't care that "Cupertino" means "America/Los_Angeles" (and probably don't want to get Theory.html cited at them to explain *why* "Cupertino" means "America/Los_Angeles") or....
The key here is "the user wants the times displayed right", not "the user wants to fiddle with tzdb IDs". Obviously, for clocks set to some time zone other than "local, whatever that might be", the user has to specify a location rather than have their location used automatically, but they care about *locations*, not about *tzdb regions* identified by tzdb IDs.
More information about the tz