[tz] draft of change summary for next tz release

[Guy Harris]

On Sep 17, 2013, at 6:46 PM, David Patte ₯ <dpatte at relativedata.com> wrote:

> Yes, but you are removing transition dates from LMT. Thats the loss of data that concerns me. The transitions dates currently may not be accurate, as you say, but if we determine a perfectly accurate transition date for a link, that is different from the location we link to, we no longer have a way of recording it in the database.

If by that you mean that if we link together Gondwanaland/Central_City and Gondwanaland/Coast_City because their post-Epoch history is the same, and later determine that they adopted standard time in different years, we have no way of recording that in the database, the answer is "yes, we just break the link".

Before breaking the link, we have two tzids, Gondwanaland/Central_City and Gondwanaland/Coast_City, which, on UN*X systems using zic, are handled by one compiled file with two hard links to it.

After breaking the link, we have two tzids, Gondwanaland/Central_City and Gondwanaland/Coast_City, which, on UN*X systems using zic, are handled by two separate compiled files.

Other systems might think that the existence of a Link line means that one of those is the "real" tzid and the other is an alias, but it's wrong of them to think so, and I think we should make that very very very very clear in the Theory document.

(And, yes, this means that

	http://norbertlindenberg.com/ecmascript/intl.html#sec-6.4.2

should continue to treat the "backward" file as special, with paragraph 2 changed to

	If ianaTimeZone is a Link name *that appears in the “backward” file of the IANA Time Zone Database*, then let ianaTimeZone be the corresponding Zone name as specified in that file.

Only links in the "backward" file should be treated as aliases, all others should be treated as "for now, these two tzids behave the same, but that's not guaranteed to remain true forever".)