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

[Paul Eggert]

On 11/16/23 14:43, Guy Harris wrote:

>> (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.
> 
> So even POSIX, in effect, tells people "don't assume tm_isdst means 'this is daylight saving time'".

Not sure what is meant by "in effect". POSIX says "The value of tm_isdst 
shall be positive if Daylight Savings Time is in effect, 0 if Daylight 
Savings Time is not in effect, and negative if the information is not 
available." 
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html>

So the intent of POSIX is that tm_isdst>0 means daylight saving time. 
The DST offset from UT need not be greater than the standard-time 
offset. POSIX (and TZDB) even allow the two offsets to be equal, though 
there's not much use for that.


> POSIX does not appear to require that tzname[0] or tzname[1] retain the same values over time

That's true if you set TZ to a value like 'America/Detroit' because 
POSIX doesn't specify the behavior for such TZ settings. However, if you 
set TZ to a POSIX-specified value like 'IST-1GMT0,M10.5.0,M3.5.0/1' then 
tzname[0] and tzname[1] have specified values - in this case, "IST" and 
"GMT" respectively.

By the way, Draft 3 of the next POSIX standard requires support for TZDB 
Zones, e.g., TZ='Europe/London'.


> Requiring tm_zone may cause binary-compatibility issues for OSes that don't currently have it and for which the supplier seeks Single UNIX Specification certification.

There definitely are binary compatibility issues, since growing a struct 
is a hassle. This is true regardless of whether the system is SUS certified.


> That would raise the question of how long-lived a struct tm is.

That's reasonably straightforward. With localtime the char * member's 
lifetime survives until TZ is modified; this is what Draft 3 of the 
next POSIX standard says. On platforms with localtime_rz the member 
survives until the corresponding timezone_t is tzfree'd.

In hindsight perhaps tm_zone should have been char[TZNAME_MAX + 1] as 
that solves the lifetime problem (and lessens the temptation to read too 
much into those abbreviations :-), but it's too late to change this now.