[tz] draft of change summary for next tz release

Stephen Colebourne scolebourne at joda.org
Wed Sep 18 09:44:30 UTC 2013


On 18 September 2013 02:32, Russ Allbery <rra at stanford.edu> wrote:
> David Patte ₯ <dpatte at relativedata.com> writes:
>> Maybe I am misunderstanding, but doesn't this proposal, in effect,
>> removes the ability of us documenting improved transition dates in areas
>> outside of the active regions?
>
> No, any zone that's turned into a link can be trivially turned back into a
> zone with its own rules with no user-visible impact.

On 18 September 2013 09:19, Guy Harris <guy at alum.mit.edu> wrote:
> 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.

Both these comments are perfectly reasonable. A Link can, in technical
terms, be converted back to a Zone if additional researched/reliable
data is found. However, it is my understanding of Paul's comments that
he will refuse to do so:

Me:
None of the above should stop existing Zone and Link entries from
being expanded with researched historic data. ie. pre-1970 data for
the existing set of IDs should remain in the main files...
http://article.gmane.org/gmane.comp.time.tz/7171

Paul:
That doesn't follow.  If the main files currently have a link, and we
want to turn this into a zone only because of pre-1970 data, we want
to keep it a link in the main file, so that we can support existing
implementations that are based on the typical current practice.
http://article.gmane.org/gmane.comp.time.tz/7175

Me:
Furthermore, had someone provided detailed pre-1970 data for
America/Aruba a year ago, I think you would have accepted it. Yet you
are arguing that now you've made it a Link you can no longer accept
it. I would suggest that isn't logical or best practice.
http://article.gmane.org/gmane.comp.time.tz/7178

Paul:
No, we've excluded similar pre-1970 data in the past, e.g.,Europe/Zagreb.
http://article.gmane.org/gmane.comp.time.tz/7181

Based on this I infer that the conversion from Zone to Link is not
temporary, but permanent. There will be no way to reinsert the data
into the main tzdb (it might be reinsertable into a
secondary/extended/pre-1970 file, but not the main data set as
currently designed).

As such and from my perspective, the changes under discussion result
in a permanently worse set of data for source code consumers like Java
and PHP which rely on accurate data for each ID (and don't care about
the Link vs Zone or zic compiled data size).

My strong preference is to retain this kind of data (reverting the
deletions) until there is some alternate means of representing it and
a long enough period for source code data consumers to adapt their
parsers (ie. at least 6 months).

Stephen


More information about the tz mailing list