On 9 July 2014 16:16, Paul Eggert <eggert@cs.ucla.edu> wrote:

Stephen Colebourne wrote:

...

As we have discussed before, changes like this are disruptive to many people. The LMT and early time values are used out there, irrespective of their accuracy.

It was discussed at some length, and to some extent we're just repeating that discussion now. There's one thing new, though: we now have had significant practical experience. The earlier set of changes along these lines was published in release 2013e (2013-09-19), and it hasn't caused significant disruption in the field. In practice it seems that end users don't much care about things like the time zone of Guadeloupe in 1899 -- which is probably a good thing, since the pre-2013e database was wrong anyway.

Well it seems that you're going to make the change no matter what, so talking about it does feel rather futile. Its no surprise that changing relatively minor locations results in few issues. Nor is it a surprise that this list wouldn't hear of any issues, because its so far from end users. I can guarantee that the data you have and are planning to destroy is in somebodies database somewhere as both Joda-Time and Java SE 8 expose the full data right back to and including LMT to all users for all zones. As I said last time, the issue isn't removing wrong values, its about replacing them with even more wrong ones. The LMT values in particular, which used to have some meaning, now do not. If you had proposed an alternate way to define LMT values (which were based on the actual city location) then I might be less frustrated. Instead we are back to taking a sledgehammer to data that wasn't causing anyone any harm, replacing it with data that is clearly worse. <shakes head in despair> Stephen

I also agree with Stephen and Derick on this Database records, in any database, should not be merged just because they contain the same data. My feeling is that the relationship of the records in question is coincidental, and therefore the records should remain separate. On 2014-07-10 11:41, Derick Rethans wrote:

On Wed, 9 Jul 2014, Stephen Colebourne wrote:

...

On 9 July 2014 16:16, Paul Eggert <eggert@cs.ucla.edu> wrote:

...

Stephen Colebourne wrote:

...

As we have discussed before, changes like this are disruptive to many people. The LMT and early time values are used out there, irrespective of their accuracy. It was discussed at some length, and to some extent we're just repeating that discussion now. There's one thing new, though: we now have had significant practical experience. The earlier set of changes along these lines was published in release 2013e (2013-09-19), and it hasn't caused significant disruption in the field. In practice it seems that end users don't much care about things like the time zone of Guadeloupe in 1899 -- which is probably a good thing, since the pre-2013e database was wrong anyway. Well it seems that you're going to make the change no matter what, so talking about it does feel rather futile. Its no surprise that changing relatively minor locations results in few issues. Nor is it a surprise that this list wouldn't hear of any issues, because its so far from end users. I can guarantee that the data you have and are planning to destroy is in somebodies database somewhere as both Joda-Time and Java SE 8 expose the full data right back to and including LMT to all users for all zones.

As I said last time, the issue isn't removing wrong values, its about replacing them with even more wrong ones. The LMT values in particular, which used to have some meaning, now do not. If you had proposed an alternate way to define LMT values (which were based on the actual city location) then I might be less frustrated. Instead we are back to taking a sledgehammer to data that wasn't causing anyone any harm, replacing it with data that is clearly worse. Let me just voice my agreement to this statement.

cheers, Derick

--

David Patte ₯ wrote:

the relationship of the records in question is coincidental, and therefore the records should remain separate

This is a good point, and in some cases in hindsight I went too far in merging zones that were coincidentally the same (e.g., merging Antarctica/Syowa with Africa/Nairobi), so I'll undo those changes soon. However, in many cases the relationship is not coincidental, as we're talking about most-likely-invented data from a single source, and for these cases we can safely discard the spurious data. This is not a question about optimizing the implementation; it's a question of having the tz data reflect our knowledge as accurately as the current format allows. Currently the tz database pretends to know more than it does, and to the extent that we can make it more honest and accurate we should do so.

On Wed, Jul 09, 2014 at 08:16:12AM -0700, Paul Eggert <eggert@cs.ucla.edu> wrote:

repeating that discussion now. There's one thing new, though: we now have had significant practical experience. The earlier set of changes along these lines was published in release 2013e (2013-09-19), and it hasn't caused significant disruption in the

Something else is new, too: in the past, changes didn't have to cause "significant disruption in the field" to not be done. For example, a lot of care was used to make the tzcode portable even to weird and niche systems that, in many cases, probably don't even exist. You could doubtlessly rip out a lot of code without causing "significant disruption in the field" (if it works on gnu/linux, bsd and solaris, then failure probably isn't signficant...). The question is, why have these standards changed so drastically w.r.t. tzdata?

field. In practice it seems that end users don't much care about things like the time zone of Guadeloupe in 1899 -- which is probably a good thing, since the pre-2013e database was wrong anyway.

I think almost everybody agrees to that.

other reasons anyway. Besides, the tail should not be wagging the dog here: regression testing should be our servant, not our master.

You are shooting down your own strawmen here. In previous discussions, most people seem to have been concerned about stability of timestamps. not about accuracy, correctness or regression testing. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\

Tim Parenti wrote:

Whatever happened to having one zone per ISO-coded region?

That's never been the guideline -- all we've had per country code is at least one entry, which may be a Link, not a Zone. Africa/Juba is a recent example; Europe/Vatican an older one. I hope your other specific concerns should be addressed by the partial-reverts that I'll propose soon. More generally, though, I fear that the data in question -- and I'm including the entries in the 1950-1970 range -- are so bogus that we do not do our users favors by propagating them.

I can't prove it, but I have the strong impression that most of the entries that we haven't already checked were simply invented.

I think that's the key there. I realize the accuracy of Shanks has come into question lately, but I think that until data is proven bogus, stability trumps this suspicion. Unfortunately, we all know how difficult it can be to prove OR disprove this data. -- Tim Parenti sent from my Android phone

On 11/07/14 08:04, Alan Barrett wrote:

On Thu, 10 Jul 2014, Paul Eggert wrote:

...

I doubt whether there's a genuine lack of concern about accuracy or correctness. On the contrary, I think we all want the data to be as accurate and correct as it can be. The only dispute here is how much stability trumps these other concerns.

Here's where I'd draw the line: If we obtain new information with higher assurance than the old information (or guesses), then we should update the database with the new information, for the sake of accuracy. If we believe that the old information has low assurance, but we do not have higher assurance information to replace it, then we should leave the old information in place, for the sake of stability.

For example, if you believe that the date that a zone switched from LMT to a standard time with a "round number" offset from UT is just a guess with low assurance, then leave it alone, until better information becomes available; don't link the zone to another zone that was similar but had a different "guess" for the data of the switch from LMT to a standard time. If you learn better information, then adjust the database accordingly.

I had thought there was an agreement that accurate historic data would be retained when the previous cull was proposed even though the 1970 limit is used? There are still documented historic updates which have not been included, and I hope that moving forward as other archives become available, proven historic data will be incorporated? Some of the 'invented' material IS of concern, but a portion of that is simply a matter of when a country started using timezones. Exact dates may not be available but that some historic changes happened is a fact? We just may never be able to confirm a proven date? -- 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

On Thu, Jul 10, 2014 at 09:58:29PM -0700, Paul Eggert <eggert@cs.ucla.edu> wrote:

The standards haven't changed. Nor are the proposed changes

As a long-time lurker, I beg to differ. Maybe the word "standards" is misleading, but the effective maintainance has definitely changed. Never before did I hear that changes from one set of (likely bogus) data to another set of (likely bogus) data is ok because it doesn't cause "signficant disruption".

entries are. They're really bad. I can't prove it, but I have the strong impression that most of the entries that we haven't already checked were simply invented. If I'd known how bad they were I would not have put them there in the first place.

That may well be, but replacing one set of invented data by another set of invented data doesn't seem to be an obvious improvement.

...

most people seem to have been concerned about stability of timestamps. not about accuracy, correctness or regression testing.

I doubt whether there's a genuine lack of concern about accuracy or correctness.

Who is concerned that the older data is less accurate/correct than the newer one and therefore the data needs to be changed?

On the contrary, I think we all want the data to be as accurate and correct as it can be. The only dispute here is how much stability trumps these other concerns.

What other concerns? The new data isn't more accurate or more correct than the old one, it's just different. Correctness and accuracy do trump stability, but neither accuracy nor correctness seem to be involved in this change - the change simply lumps together zones because the pre-1970 data was deemed incorrect, without there being reason to believe that this merge improves either correctness or accuracy. People in this discussion primarily complain about needless instability, not about instability caused by fixes. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\

The charge is that this is "changes from one set of (likely bogus) data to another set of (likely bogus) data ". Simply because you think it hasn't caused issues does not make it so. Those of us who listen to this list are the consumers and customers of this data, and our feedback should inform on the desirability of change. Yet every other person who has responded to this thread has questioned this change and indicated they would prefer it not to occur. What has to happen to make it stop? No one has an issue with changing data to make it better. Everyone has an issue with changing data from possibly bogus to possibly bogus. Standard maxim - if it ain't broke don't fix it. Stephen On 11 July 2014 19:51, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 07/11/2014 07:19 AM, Marc Lehmann wrote:

...

Never before did I hear that changes from one set of (likely bogus) data to another set of (likely bogus) data is ok because it doesn't cause "signficant disruption".

Even if you didn't hear about it, we have done changes like that in the past, and we did not encounter problems in the field because the changes were done reasonably conservatively, just as the current set of changes will be done reasonably conservatively once things are ironed out. I appreciate having more eyes to check over the changes these days to make sure that significant disruptions will not ensue, and so far we've gotten useful reports from Alan Barrett, Tim Parenti, and David Patte along these lines, which will improve the quality of the database.

We do make mistakes, and generate a release that does cause significant disruption. The most recent example of this was the disruption caused by the 2014c release, which broke GNOME's Glib. Testing to avoid significant disruption to end users should focus on those sorts of issues; in contrast, there's no real need to worry about minor adjustments to the placeholder UT offset of Upper Volta in 1911.