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

[Guy Harris]

On Nov 16, 2023, at 6:29 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> 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.

...which means that the phrase "Daylight Savings Time" in the POSIX standard refers to something that's not exactly the same as "daylight saving time" as generally understood, i.e. it doesn't necessarily mean "the time that's in effect during summer and possibly some close-to-summer dates in spring and autumn, if clocks are adjusted twice a year, with the clock setting during summer and blah blah blah being ahead of the clock setting during the rest of the year".
or...).

POSIX at least defines "seconds since the Epoch", to make it clear that it doesn't mean the number of SI seconds that have elapsed since the Epoch; it does not appear to define "Daylight Savings Time", but, if it uses it, it should do so, given, for example, the case of the Republic of Ireland.

>> 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.

But if the system isn't SUS-certified, and the supplier doesn't intend to have it be SUS-certified, they can just say "too bad, POSIX may require tm_zone, but we don't do POSIX, so we're not doing tm_zone.  That's how SUS certification matters here.

Apple has no problem, as they've had tm_zone since, as far as I know, Day One.  (Maybe it wasn't in Rhapsody or Mac OS Server 1.0, but I think it was there going all the way back to 10.0/Cheetah.  The Libc project source for 10.0 has it; I'm not sure what project has the header files.)

As for non-SUS-certified systems:

The *BSDs aren't going for SUS certification, but they've had it for ages - possible ever since they picked up the tz code.

GNU libc currently has it, albeit with a #define to control whether to pollute the namespace with a structure member named tm_zone or to slap enough underscores in front of tm_zone to make it safe, so many Linux distributions have it.  I don't know whether any of the alternative C libraries, such as musl, have it. (EulerOS and Inspur K-UX were certified Linux distributions at one point, but they didn't renew the certification.)

And as for the biggest non-embedded Linux distribution of all, bionic appears to have tm_zone (by virtue of libc/include/time.h 1) having it in struct tm and 2) defining TM_ZONE to be tm_zone).

>> 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.

So they took the simplest approach; that means that code using tm_zone needs to be careful with those strings, but that's *already* the case, as no stronger guarantees are, as far as I know, offered either by the tz code or the equivalent in various other libc implementations.

(Now when's Microsoft going to join the party - and not just in the Linux distributions running atop WSL?)