[tz] Error in Scandinavian tz data

[Paul Eggert]

On 2023-06-27 01:35, Stephen Colebourne via tz wrote:
> The simplest approach would be to determine a rule, eg.
>   - take the standard offset that applied on most days (modal average)
> for the 5 years from 1970 to 1975 - and use that pre-1970.
> - or, take the LMT of the city and round to the nearest hour
> So long as the answer is reasonable for most cases, it would be fine.

This would take the existing TZif files (admittedly problematic, as you 
say) and make them worse, as they'd become wrong for every location, 
even the location that names the Zone.

Surely it would be better to discard the pre-1970 data - then users 
would be on notice that it's missing. And there's a standard way to do 
that, documented in the Makefile: use 'make ZFLAGS=-r at 0'. Perhaps this 
option should be documented more prominently.

It's not clear that -r at 0 should be the Makefile default, though, as that 
could well cause more trouble than it would cure. For example, it would 
cause the following behavior:

	$ export TZ=Europe/Copenhagen
	$ date -r 1; date -r 0; date -r -1
	Thu Jan  1 01:00:01 CET 1970
	Thu Jan  1 01:00:00 CET 1970
	Wed Dec 31 23:59:59 -00 1969

and the UT offset zero and abbreviation -00 of pre-1970 timestamps would 
likely give many users pause. That being said, in installations not 
needing pre-1970 timestamps, -z at 0 is a clear win.

Getting back to Anders's original question, one can get behavior closer 
to what he asked with something like this:

make PACKRATDATA=backzone PACKRATLIST=zone.tab install

although I don't recommend this for ordinary applications. One should 
treat the result with a grain of salt as it's likely wrong for 
Copenhagen and it's certainly a bit wrong for Aarhus etc. This is a 
hazard of trying to push tzdata further than it can reliably bear.