[tz] Yukon to move to year-round PDT

[Paul.Koning at dell.com]

> On Mar 5, 2020, at 8:45 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> 
> 
> [EXTERNAL EMAIL] 
> On 3/5/20 5:31 PM, Paul Goyette wrote:
>> Doesn't such a position, however, fly in the face of the "boots on the
>> ground" approach we've taken in other situations?
> 
> Yes it does. But then, we consistently flew in the face of that approach in the past when this situation arose, so at least we'd be *consistently* inconsistent. (There is a technical obstacle to having a time zone observe DST indefinitely, as this can't be implemented via POSIX TZ strings on many platforms.)
> 
> Another possibility would be to put "-07" into the database for now, until we find out what abbreviation (if any) people actually use once the timestamps diverge in November. If people end up using "PDT" next winter in Yukon we can put that into the database, even though it will be odd that it's "PDT" even though the is_dst flag will be 0 due to the abovementioned technical obstacle.
> 
> I've been fearing this technical snafu for many months as the "permanent DST" movement has gained steam in North America.

I view isdst as valid only if there are two time offsets, active at different times according to something resembling a rule.  Normally "isdst" means summer time, with one or two oddball exceptions.  But when only one rule is in effect year-round, it doesn't make sense to set the "non-standard" flag, which is what "isdst" is.

So never mind the "technical obstacle"; set is_dst 0 as a matter of principle no matter whether POSIX justifies it or not.

	paul