moderated 'Timezone' drop-down menu in Calendar considered harmful #suggestion


Chip Davis <chip@...>
 

The 'Timezone' drop-down menu for a calendar event is causing a great deal of misunderstanding, and has an easy fix.

The Groups.io mavenry assure us that event times "just work" if one specifies the timezone appropriate to the time-of-day of the event.  Accommodation for Daylight Saving Time is handled by the Calendar software.

That's all well-and-good, except that the Timezone drop-down menu itself specifies a value for DST.  For example, DST is in effect today on the East Coast, so when I schedule an event for next week, the Timezone drop-down correctly offers:
    (UTC-04:00) Eastern Time - New York (EDT)
However, if I am scheduling a Christmas party on Dec. 20, 2022, which is obviously not in DST, the Timezone drop-down reads exactly the same.

The first thing most people do then, is to scroll around the list looking for the correct '(UTC-5:00) Eastern Time - New York (EST)' entry, which is not there.  The next thing they try is to compensate for that lack and specify a time earlier or later by one hour, and hope they got the conversion going in the proper direction.  The recommendation from the Groups.io mavenry is to just specify the time and the proper zone, and it will all come out right.  But that creates cognitive dissonance due to the obvious mismatch.

The fundamental problem is one of over-specificity:  There is no reason for the Timezone drop-down list to mention anything about DST (or UTC offsets) in the first place.  If the Timezone drop-down entry had been simply:
   Eastern Time - New York
there would be no confusion, and the assumption would be that the software will make the necessary adjustment when time comes.  As it apparently does.

This is an easy fix.


Bruce Bowman
 

On Wed, Mar 30, 2022 at 10:37 AM, Chip Davis wrote:
The fundamental problem is one of over-specificity:  There is no reason for the Timezone drop-down list to mention anything about DST (or UTC offsets) in the first place.  If the Timezone drop-down entry had been simply:
   Eastern Time - New York
there would be no confusion, and the assumption would be that the software will make the necessary adjustment when time comes.  As it apparently does.
This suggestion is couched in the notion that every time zone has an unambiguous "name" of some kind and elimination the UTC designations won't lead to problems elsewhere.

Is that assumption valid? Not sure that it is, worldwide. Many countries don't recognize DST at all, and look at Chatam Time (UTC+13:45). Wow.

I'm not pleased about any of this, but it may very well be that the UTC information is a necessary evil. 

Regards,
Bruce


Chip Davis <chip@...>
 

I submit that the residents of the "outlier" timezones without an unambiguous name know very well which established timezone is appropriate for their use, and when.

Residents of countries that do not adjust for DST already have to be aware of, and adjust for, our DST changes.  I assure you that the lucky residents of the Chatham Islands are well aware of the issue and do it in their heads, as do those in Vincennes, Il.  I've flown into Broken Hill, NSW, where those hearty Aussies have no problems with their UTC+09:30 timezone.

All of your concerns can be easily ameliorated by simply adding twenty-four "UTC-only" entries to the 'Timezone' drop-down list (or more if you want to specify every non-hourly UTC-offset in use on the planet).  It's hard to image that the current Groups.io code handles such outlier cases now.

I'm a member of several aviation groups; we pilots use UTC all the time - all of the clocks in my office (and my phone) display Zulu time.  When you regularly cross multiple timezones, or are coordinating meetings globally, the various local DST settings are a major PITA.

My solution is cleaner and less confusing, but the other solution is to list both DST values for every timezone (if any).  The downside is that the user making a calendar entry must know which entry applies, and we've just violated the "it just works" paradigm.

-Chip-


Henning Schulzrinne
 

All modern operating systems and programming language libraries internally use the tz database, with city-based naming that takes into account DST, as in America/New_York. See https://en.wikipedia.org/wiki/Tz_database

This has the advantage that any updates to DST, as is being discussed in the US and has happened a fair amount internationally, gets reflected in the calendar entry, without having to worry about what offset was meant at the time.

In some cases, it's helpful to specify the common local name, such as "ET" (Eastern Time).

-- Henning


 

On Wed, Mar 30, 2022 at 7:37 AM Chip Davis <chip@...> wrote:
The 'Timezone' drop-down menu for a calendar event is causing a great deal of misunderstanding, and has an easy fix.


I've removed the DST information from the timezone drop down. I've kept the UTC offsets, as that seems to be pretty standard in the other services I've looked at.

Thanks,
Mark


Chip Davis <chip@...>
 

That's a fair compromise, Mark.  Most non-pilot, non-global-travelers I know, don't have a clue what their UTC-offset is anyway.  The major source of confusion was due to the entries specifying a specific DST setting that was not correct for the date in question.

Thank you for seeing the value in the suggestion,

-Chip-

On 4/6/2022 12:36 PM, Mark Fletcher wrote:
On Wed, Mar 30, 2022 at 7:37 AM Chip Davis <chip@...> wrote:
The 'Timezone' drop-down menu for a calendar event is causing a great deal of misunderstanding, and has an easy fix.


I've removed the DST information from the timezone drop down. I've kept the UTC offsets, as that seems to be pretty standard in the other services I've looked at.

Thanks,
Mark



Jeremy H
 

The problem with keeping the UTC offsets is that about half the time they are wrong. While (using my time) today it is correctly United Kingdom Time (UTC+01:00), skipping forward to a November date (when we will be back on Winter Time = GMT = UTC+00:00), that will be wrong. So setting time for a new event, should I choose that (United Kingdom Time (UTC+01:00)), or find a different drop down entry, which has UTC+00:00.?

To my mind UTC offsets should only be there for times which are actually defined that way (or are by definition tied to a specific offset, e.g. GMT, BST, EST, AEDT). Where time is for country or city (where the offset will or may change), it should be omitted, reliance being placed on the software to sort things out) 

Jeremy


On Wed, Apr 6, 2022 at 05:36 PM, Mark Fletcher wrote:
I've removed the DST information from the timezone drop down. I've kept the UTC offsets, as that seems to be pretty standard in the other services I've looked at.
 
Thanks,
Mark
 

 

 


Chip Davis <chip@...>
 

That was exactly the argument in my original #suggestion, Jeremy.

I accepted Mark's partial solution as an improvement, if not his weak "Google Calendar does it that way" argument for it.  Groups.io was supposed to be an example of doing online global collaboration right, not just a "Mailman++".

Pardon my ethnocentricity, but I have no doubt that most Americans have no clue (or care) what their GMT-offset is, so his partial solution is (sadly) acceptable for the US market.  But there is really no valid argument for listing the wrong GMT value in a drop-down list meant for the entire world.

-Chip-


Duane
 

On Thu, Apr 7, 2022 at 07:13 AM, Chip Davis wrote:
I have no doubt that most Americans have no clue (or care) what their GMT-offset is
Other than pilots, military, and amateur radio operators (in general), that's probably true.  (As a retiree, day or night is close enough for me...)  One solution is to list times as GMT/BST, CST/CDT, etc. without the UTC reference.  Hopefully people would understand that the calendar will adjust itself for the time of year (when sending reminders and such) so you don't need to change the scheduled time to offset for it.  Even better would be to omit any reference to summer/daylight, standard, or UTC time as Chip has mentioned, resulting in basically a 'local' time.  You'd only have AT(Atlantic Time) or GT(Greenwich Time), though there are many areas where there is no official minimalist name for the time zone.  A third scenario would be for the calendar to keep track of the time zone that would be in use for any date so that the drop down list would have the correct UTC offset (a nightmare! ;>).  Any option would likely require some serious time investment.

Duane
currently CDT


Andy
 

For me, Windows tells me that my time zone is "(UTC-05:00) Eastern Time (US & Canada)", where the words are a reasonably good way of putting it in terms that even most Americans can understand -- even though it has the wrong time offset for most of the year.  It is puzzling that I am about as likely to see it written as either "UTC-04:00" or "UTC-05:00", where they both mean the same exact thing.  One would have thought that the 'experts' should have figured this out by now.  But I put too much faith in them.

Even more confusing is when I see it written as "UTC+05:00" but it means the same time zone.  I'm pretty sure that's wrong, but I have seen it.  Recently, in fact.  Arrgh!

Andy


Chip Davis <chip@...>
 

This problem is caused by conflating two values, one geographical and unchanging, with one governmental that changes twice a year.  Or doesn't.

The Calendar "Timezone" drop-down list should display only that: the timezone of the location in which the event is being scheduled.  No one needs to know the UTC-offset or DST status to make an entry in the calendar.  They simply want to schedule a meeting four months from now at 11:00am in Chicago.

For half of the year, the UTC-offset in the "Timezone" list is wrong, which confuses two groups of users:
 1. Those who don't know what it means but know that it doesn't match their computer's Date/Time setting.
 2. Those who do know what it means and can't find the correct UTC-offset in the list.

There are two ways to properly handle this issue:
 1. Make the "Timezone" drop-down list smart and display the appropriate DST-dependent values (UTC-offset, timezone name and abbreviation) to accurately reflect the date being scheduled.  That's the way the calendar on my Android phone works.  That's not a SMOP for Groups.io, given the lack of reliable user location data.
 2. Remove all DST-dependent references (now only UTC-offset) from the "Timezone" drop-down list.

If users really needs to know their location's UTC-offset for any reason, Google is their friend.

-Chip-


Andy
 

On Thu, Apr 7, 2022 at 12:44 PM, Chip Davis wrote:
For half of the year, the UTC-offset in the "Timezone" list is wrong, ...

But that's the thing.  In (about) half of the places I look, the offset is right; and in the other half it is wrong.

Currently, Microsoft Windows shows me the wrong time offset, and Groups.io's Calendar shows me the currently-correct time offset.  Yet they both refer to the same time zone, the one that is currently in effect here.

I'm pretty handy with Zulu/UTC and converting between time zones.  But it is distressing seeing inconsistency in how they are listed.

Andy


Duane
 

On Thu, Apr 7, 2022 at 12:38 PM, Andy wrote:
Currently, Microsoft Windows shows me the wrong time offset
Windows has a setting for "observe DST" (or similar) that you can set.  If you do it correctly, the displayed time will be correct, but it will still say your time zone is, for example, UTC-06:00, Central Time.  I think Microsoft got as confused as some others by the difficulty of getting it right all the time, so just made a choice and stuck with it. ;>)

Duane