[tz] Did Greenland abolish daylight saving from 2024 on?

[Paul Eggert]

On 2023-11-13 16:48, Guy Harris wrote:
> I see three ways in which tm_isdst can be used:
> 
> 	1) as an indication of whether something known as "daylight saving
> time" or "summer time" or something other than "standard time" is in
> effect;
> 
> 	2) as an indication of whether the offset-from-UTC is advanced from
> what it would be in winter;
> 
> 	3) as an index into the tzname[] array.

(1) is the only thing that tzcode supports.

(2) is incompatible with POSIX if by "advanced" one means "greater 
offset from UT", since POSIX requires so-called "negative" DST for TZ 
settings like TZ='IST-1GMT0,M10.5.0,M3.5.0/1', the current Irish practice.

(3) might be made to work, but it'd mean that in most TZDB Zones, 
tm_isdst would be nonzero for timestamps that pretty much everybody 
would consider to be standard time. For example, tzdata says 
TZ='America/Detroit' has observed standard time with abbreviations 
"LMT", "CST", and "EST" in the past, and at most one of these could get 
tm_isdst==0. Besides, with tzcode time zone abbreviations should not be 
deduced by inspecting tm_isdst. Instead, one should use strftime or (if 
available) the tm_zone member of struct tm. tm_zone is better if it is 
available, which I hope will be required by the next POSIX version.

This is why <https://data.iana.org/time-zones/theory.html#vestigial> 
says "tm_isdst is almost never needed". Its only plausible use these 
days is when calling mktime, and even then it's flaky.