On Feb 26, 2019, at 9:54 AM, Fred Gleason <fredg@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 and 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.