On 11 August 2014 00:59, Paul Eggert <eggert@cs.ucla.edu> wrote:
What I find objectionable is to have a named entity (zone or link) where the LMT of the named location is replaced by the LMT of some other location.
This objection seems to be based on a misunderstanding of what the LMT entries were always supposed to mean. They never meant anything like "the time at this location was exactly 7 hours, 52 minutes and 58 seconds before GMT" (to use America/Los_Angeles as an example). Instead, they meant that the time was not closely specified: different people at that location would not have cared about minor differences in GMT offsets, or (if pushed to be specific and if knowledgable about the topic) would even have disagreed about what the GMT offsets should be.
In hindsight the tz database format should had have a specific notation for this. But it doesn't, so we use LMT entries as stand-ins. Their exact GMT offsets do not matter. It's similar to the zzz notation that we use for places while uninhabited. I suppose one could argue that the LMT and zzz notations are both abuses of the format, but we needed *some* way to say that the local time was not closely specified or was undefined, and that's what we came up with.
This seems to be missing the point (again). It does not matter what the intention of LMT in the data format was. What does matter is what it has actually been used for! In reality, the LMT value is widely available as an actual, visible, usable value in applications in many different programming environments. By all means say that we should not be in this mess, but we are, and the proposal is an incredibly simple way to reduce the effects. The concept that LMT somehow means "undefined" has been totally lost at this point. It is also an unhelpful answer, as the programming environments need *some* answer for time-zones in the far past, and right now LMT is the obvious one to pick up. Simply changing the notation from LMT to undefined would not stop the need that programming environments have for a far past value. (By the way, if a programming environment wanted to choose a value for the far past that was not LMT, the chances are that they would choose a smoothed value, exactly as proposed, because that is more in line with the expectations of normal developers)
The net effect of this would be to provide a much more regularized value for the far past (pre 1850 or later).
This makes it sound like the proposed notation would be more misleading than the current one, as it would suggest an even-more-regularized past than the current one does. We shouldn't give users the incorrect impression that long-ago timekeeping was tidy.
All values for the far past are misleading to some degree, "more misleading" is subjective. The proposal simply chooses a value that would be beneficial to the long term maintenance of the tzdb data, by replacing an unstable value by a stable value. That way, most of the link discussion goes away, for example because all of West Africa would then share the same smoothed LMT value. Finally, I will note that for those users who already understand that LMT data means "undefined", the proposal makes no difference. Those users can carry on interpreting LMT in that way. However, for those users that do interpret LMT as an actual real offset to be used for the far past (the vast majority of programming environments) the proposal provides a simpler, clearer answer. Stephen