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

[Guy Harris]

On Jan 5, 2024, at 3:16 PM, Brooks Harris via tz <tz at iana.org> wrote:

> On 1/5/2024 2:31 PM, Paul Eggert wrote:
> 
>> It's never been a goal of zic to pack as much as possible information about the input into the TZif binary output file. Instead, the goal has been to optimize the output file size, as long as optimization doesn't change localtime's behavior.
> 
> Yes, I understand, I think. But I think these "first of year" transitions should be included in TzIf. They are important to the objectives I'm pursuing because they contain the critical STDOFF shifts that are not included in the normal outzone() output. I'm including both STDOFF and DST transitions in my resulting timestamp formats.

So by "STDOFF shifts" do you mean changes that represent a timezone changing which time zone it's in :-) rather than turning the clock forward in spring and backward in autumn?

I would expect them to be included unless they coincide with a clock forward/backward shift that cancels out the STDOFF shift.  What are examples of STDOFF changes that don't show up in the TZif files?

Furthermore, at least as I read

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

they *do* affect the value of the timezone global variable, which is specified as "the difference, in seconds, between Coordinated Universal Time (UTC) and local standard time", and thus would need to be included in TZif files in order to support that variable (by changing its value to the the value in effect as of the last time converted - greasy hack, but that's what you get when you, meaning "AT&T", design an API that assumes a location never changes what time zone it's in).

>> However, I don't see how such a flag could preserve all the relevant information, without a change to the TZif file format. 
> 
> True, and I'm not suggesting TZif format should change, only that these transitions be retained.
> 
> There aren't actually very many, though I've not done a full tally. But there's only 1 in London, 5 in New York, 1 in Sydney, etc. I think this would be a very small increase in the TzIf files size.

OK, so which transition is that for Europe/London?

Europe/London has

# Zone	NAME		STDOFF	RULES	FORMAT	[UNTIL]
Zone	Europe/London	-0:01:15 -	LMT	1847 Dec  1
			 0:00	GB-Eire	%s	1968 Oct 27
			 1:00	-	BST	1971 Oct 31  2:00u
			 0:00	GB-Eire	%s	1996
			 0:00	EU	GMT/BST

The only transitions that affect STDOFF are the ones on 1968-10-27 (entering British Standard Time, 1 hour ahead of GMT) and the one on 1971-10-31 at 2:00 UTC (going with GMT in winter and British *Summer* Time in the summer).

Those appear in the Europe/London TZif file in macOS Ventura, as reported by the dump in macOS Ventura:

	Europe/London  Sun Feb 18 01:59:59 1968 UTC = Sun Feb 18 01:59:59 1968 GMT isdst=0	From Greenwich Mean Time
	Europe/London  Sun Feb 18 02:00:00 1968 UTC = Sun Feb 18 03:00:00 1968 BST isdst=1	to British Summer Time
	Europe/London  Sat Oct 26 22:59:59 1968 UTC = Sat Oct 26 23:59:59 1968 BST isdst=1	From British Summer Time
	Europe/London  Sat Oct 26 23:00:00 1968 UTC = Sun Oct 27 00:00:00 1968 BST isdst=0	to British Standard Time, with clocks not changed
	Europe/London  Sun Oct 31 01:59:59 1971 UTC = Sun Oct 31 02:59:59 1971 BST isdst=0	From British Standard Time
	Europe/London  Sun Oct 31 02:00:00 1971 UTC = Sun Oct 31 02:00:00 1971 GMT isdst=0	to Greenwich Mean Time, with clocks turned back an hour

because they involve a change to one or more of:

	the offset from UTC that's currently in effect;

	the isdst flag;

	the time zone abbreviation.

What are some examples of changes that affect STDOFF that do *not* result in transitions in a TZif file?