[tz] Unfortunate time zone names in the United States

[Philip Paeps]

On 2022-03-18 07:14:52 (+0800), Paul Eggert via tz wrote:
> On 3/17/22 14:31, Chris Walton via tz wrote:
>> Yukon recently did the same thing.
>
> When Yukon did that, we modeled that as America/Whitehorse and 
> America/Dawson being on -07 standard time all year, with the 
> abbreviation "MST". This made sense, as that's what "MST" means 
> elsewhere in North America.
>
> This new change, if it becomes law, won't be so easy to deal with. It 
> will likely cause "Pacific Time" to be synonymous with -07 and 
> "Mountain Time" to be synonymous with -06 in popular usage, which 
> means that the entries for America/Whitehorse and America/Dawson will 
> need to change from "MST" to something else, as "MST" will be 
> misleading.

The abbreviations are going to be misleading no matter what.  It's 
Malaysian Standard Time according to the National Metrology Institute of 
Malaysia https://mst.sirim.my.  As I pointed out in another thread, I 
believe we should simply do away with these abbreviations and track only 
offsets.  Overlays such as CLDR could take our "-7" and turn it into 
"Pacific Time" if they wanted to.

> It's been longstanding tzdb practice to model permanent DST as 
> standard time. Admittedly this practice has so far been employed only 
> for locations like Argentina that have fewer users. Still, the 
> precedent is there and is consistent with the traditional meaning of 
> standard time.
>
> There's another issue here: permanent DST is more likely to break 
> software applications. For example, permanent DST in California that 
> is called "PDT" and is 7 hours behind Greenwich would entail a 
> POSIX-style TZ string like TZ='XXX6PDT7,0/0,J365/23' that means 
> "California's standard time is 6 hours behind Greenwich, but it 
> springs backward to 7 hours behind Greenwich on January 1 at 00:00 and 
> springs forward on December 31 at 23:00, so it's actually on daylight 
> saving time all year". I suspect these oddball TZ strings would break 
> applications, and I doubt whether this approach would be wise even if 
> it barely conforms to the standards.

How we model this in tzdb will presumably have to depend on how the 
final legislation is written.  If it ends up being permanent daylight 
saving, and the definitions of the standard offsets are unchanged, then 
software will expect the tm_isdst flag to be set.

It's worth remembering that politicians assign a rather more flexible 
definition to the word "permanent" than laymen.

I think the modelling of tm_isdst is a completely orthogonal discussion 
to what the abbreviations end up being.  And a much more important one!


Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises