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

[Guy Harris]

On Nov 14, 2023, at 12:32 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

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

Including

# From Paul Eggert (2018-02-15):
# In January 2018 we discovered that the negative SAVE values in the
# Eire rules cause problems with tests for ICU:
# https://mm.icann.org/pipermail/tz/2018-January/025825.html
# and with tests for OpenJDK:
# https://mm.icann.org/pipermail/tz/2018-January/025822.html
#
# To work around this problem, the build procedure can translate the
# following data into two forms, one with negative SAVE values and the
# other form with a traditional approximation for Irish timestamps
# after 1971-10-31 02:00 UTC; although this approximation has tm_isdst
# flags that are reversed, its UTC offsets are correct and this often
# suffices....
#
# The following is like GB-Eire and EU, except with standard time in
# summer and negative daylight saving time in winter.  It is for when
# negative SAVE values are used.

For what it's worth, macOS Ventura 13.6's localtime() claims, in tm_isdst, that Ireland is on standard time, while Ubuntu 22.04's localtime() claims, in tm_isdst, that it's on DST.

> (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'".

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

POSIX does not appear to require that tzname[0] or tzname[1] retain the same values over time, and neither the macOS Ventura 13.6 version of tzcode:

	$ TZ=America/Indiana/Vincennes ./tzname 2006-04-03
	tzname[0] = "EST"
	tzname[1] = "CDT"
	Current tz abbreviation = "CDT"
	$ TZ=America/Indiana/Vincennes ./tzname 2010-04-03
	tzname[0] = "EST"
	tzname[1] = "EDT"
	Current tz abbreviation = "EDT"

nor the glibc time zone code in Ubuntu 22.04:

	$ TZ=America/Indiana/Vincennes ./tzname 2006-04-03
	tzname[0] = "CST"
	tzname[1] = "CDT"
	Current tz abbreviation = "CDT"
	$ TZ=America/Indiana/Vincennes ./tzname 2010-04-03
	tzname[0] = "EST"
	tzname[1] = "EDT"
	Current tz abbreviation = "EDT"

keep it having the same reason.  And, for America/Detroit:

	$ TZ=America/Detroit ./tzname 1904-01-01
	tzname[0] = "LMT"
	tzname[1] = "EDT"
	Current tz abbreviation = "LMT"
	$ TZ=America/Detroit ./tzname 1905-01-01
	tzname[0] = "CST"
	tzname[1] = "EDT"
	Current tz abbreviation = "CST"
	$ TZ=America/Detroit ./tzname 1915-05-16
	tzname[0] = "EST"
	tzname[1] = "EDT"
	Current tz abbreviation = "EST"

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

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.  For those OSes:

	Solaris's Single UNIX Specification certification has lapsed, so they may not have to add it;

	AIX is still certified;

	HP-UX *probably* doesn't have tm_zone (I don't even know if they're using the tzdb - a long time ago, I seem to remember they had their own database), but, given that they haven't said anything about an x86-64 port, and seem to be planning on offering x86-64/Linux servers with an environment in which to run HP-UX Itanium applications, I suspect HP-UX's future is limited.

If necessary, they *could* handle it.  macOS Ventura's compat(5) man page says:

     In order to provide both legacy and conformance versions of functions,
     two versions of affected functions are provided.  Legacy variants have
     symbol names with no suffix in order to maintain ABI compatibility.
     Conformance versions have a $UNIX2003 suffix appended to their symbol
     name.  These $UNIX2003 suffixes are automatically appended by the
     compiler tool-chain and should not be used directly.

which was how Apple handled some cases where POSIX conformance (starting in Leopard) would break binary and source compatibility with existing programs.

That would raise the question of how long-lived a struct tm is.  For example, what happens if you call localtime(), save the result, set the TZ environment variable in your program to some other tzid, call tzset(), and try to use the tm_zone member of the struct tm?  If tzset() frees all the data it has before loading new data, that would include freeing time zone abbreviations.

> This is why <https://data.iana.org/time-zones/theory.html#vestigial> says "tm_isdst is almost never needed".

And, in fact, says:

	The tm_isdst member is almost never needed *and most of its uses should be discouraged in favor of the abovementioned APIs*.

so it's not just descriptive, it's prescriptive, which is a Good Thing.

> Its only plausible use these days is when calling mktime, and even then it's flaky.

The C and POSIX standards should probably warn that using anything other than -1 (or any other negative number) for tm_isdst may not give you what you think you want.  The SUS currently says

	A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time.

I guess "presume initially" is somewhat weasel-wordish and could be read as not saying too much about what will happen, but something stronger might be better.