[tz] [PATCH] Replace some zones with links when that doesn't lose useful info.
David Patte ₯
dpatte at relativedata.com
Thu Jul 10 16:35:32 UTC 2014
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
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 at 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.
More information about the tz