[tz] draft of change summary for next tz release

Lester Caine lester at lsces.co.uk
Wed Sep 18 09:17:51 UTC 2013

Guy Harris wrote:
> On Sep 17, 2013, at 8:39 PM, David Patte ₯ <dpatte at relativedata.com> wrote:
>> So, are you saying that wherever our best guess that the transition from LMT to standard time is different, they should be kept as separate - not linked?
> No.
> I'm saying that if we were to get rid of that transition information (if, for example, we have little confidence in it), and make some tzdb zones Links to another zone when, with the removal of the transition information, they have the same information, that does not prevent us from later putting the transition information back in (if, for example, we get more reliable information) and making those tzdb zones separate again.
> Removing the transition information would, obviously, mean that it would not currently be in the database, but it would *NOT* mean that we could never put it back in.
> (That does raise the question of what should be done if not all locations within a tzdb zone adopted standard time on the same date:
> 	"split the zone" means creating zones that would probably be of no interest to many end-users (I suspect a large fraction of the localtime() calls on my machine convert times that result from stat() and company. and few if any of those date back to the previous millennium, much less before the adoption of nationwide standard time in the US), so I don't think we should do that until we have some way for packagers of the tzdb to winnow out that stuff;
> 	"pick a location in the zone and use that" gives wrong answers for locations other than the one chosen and locations that went to standard time on the same date.)

No need to shout ... nothing I've said implied we could not put data back, but 
what I'm going on about here is that currently people are USING data with these 
values in. *YES* correcting data in the future is the target, but changing one 
assumption for another short term is simply wrong. So I'd prefer to maintain 
that information and I'm happy that it's simply moved to the 'extended' data store.

Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

More information about the tz mailing list