[tz] Extra transition for Europe/London with 2023d

[Guy Harris]

On Jan 6, 2024, at 9:55 AM, Brooks Harris via tz <tz at iana.org> wrote:

> I think the difficulty originates with Posix-time itself which has no method to signal STDOFF,

The page at

	https://pubs.opengroup.org/onlinepubs/9699919799/functions/daylight.html

says

	The tzset() function also shall set the external variable daylight to 0 if Daylight Savings Time conversions should never be applied for the timezone in use; otherwise, non-zero. The external variable timezone shall be set to the difference, in seconds, between Coordinated Universal Time (UTC) and local standard time.

That says "local standard time", not "local time".

And the page at

	https://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html

says

	The localtime() function shall convert the time in seconds since the Epoch pointed to by timer into a broken-down time, expressed as a local time. The function corrects for the timezone and any seasonal time adjustments. [CX] 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [Option Start].gif
Type: image/gif
Size: 69 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20240106/33c8e9d4/attachment.gif>
-------------- next part --------------
  Local timezone information is used as though localtime() calls tzset().

which can be read as meaning that all of the things that the tzset() function is specified as doing could occur as a result of a localtime() call, so presumably a localtime() call could set the timezone variable.

The first of those pages doesn't say what "the difference, in seconds, between Coordinated Universal Time (UTC) and local standard time" is if its value is itself dependent on date and time, which is one of the problems with the POSIX time API.

> the isdst flag is insufficient to signal so-called "double summertime" or negative DST shifts

Yes, it treats DST as an on-off thing, and doesn't specify what "daylight saving time" means.

> and, of course, leap-seconds.

*That* is a problem with the specification of POSIX time in

	https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html

which defines "seconds since the Epoch" in a way that always has 86400-second days.  The POSIX *API* is capable of indicating leap seconds - the page at

	https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

specifies (following the ISO C standard - thanks to Doug Gwen for getting the original ANSI C standard for specifying this!) that the maximum value of tm_sec is 60, not 59.  However, a POSIX-compliant system will never set tm_sec to 60, given the way "seconds since the Epoch" is defined.

> This leaves TzDb responsible to 'trick' the Posix time (localtime() and mktime()) into yielding the Posix YMDhms representation (broken-down time) by manipulating gmtoff while holding stdoff to some fixed value. In common cases this works ok but in many situations, such as STDOFF shifts, STDOFF shifts simultaneous with DST shifts, or "double summertime" the TzIf values are essentially 'lying' to work around the Posix insufficiencies. Until Posix-time is improved TzDb will be forever inventing work-around manipulations of the Posix-time. One might hope the Posix folks might recognize this and find ways to address it.

Just as with POSIX there's the specification of "POSIX time" ("seconds since the Epoch") and of the POSIX time API, with TZDB there's the format of the air source files, the format of a TZif compiled file, and the tzdb code, which implements a superset of the POSIX time API.

Not all users of the TZDB data use the tzdb code.  Some use the source files rather than the TZif files, and I think some use the TZif files but have their own code to read them (I think International Components for Unicode does so, at least from what I remember from Apple - Deborah?).  That code is *not* constrained by the limitations of the POSIX API, but code that reads TZif files is constrained by what information is stored in the files.  In particular, nothing in the TZif file format splits the offset-from-UTC into "standard time offset from UTC" and "daylight saving time adjustment from standard time".

The TZif format is documented in RFC 8536:

	https://datatracker.ietf.org/doc/html/rfc8536

It defines "Daylight Saving Time" as

	The time according to a location's law or practice, when adjusted as necessary from standard time. The adjustment may be positive or negative, and the amount of adjustment may vary depending on the date and time; the TZif format even allows the adjustment to be zero, although this is not common practice.

It defines a "Time Change" as

	A change to civil timekeeping practice. It occurs when one or more of the following happen simultaneously:

		1. a change in UT offset

		2. a change in whether daylight saving time is in effect

		3. a change in time zone abbreviation

		4. a leap second (i.e., a change in LEAPCORR)

A change from DST to double DST would be a "Time Change", as it would result in a change in UT offset.  It would not change whether DST is in effect.

A change in the standard-time offset of the timezone from UTC would probably be a "Time Change", as it would probably result in a change to UT offset.

> I see no harm to typical behavior of Posix-time by providing these other "no-op" transitions to assist applications that can make use of them.

So what are examples of how an application would make use of this information?