[tz] draft of change summary for next tz release
guy at alum.mit.edu
Wed Sep 18 08:19:58 UTC 2013
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?
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.)
More information about the tz