[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change

[Robert Elz]

  From: Stephen Colebourne <scolebourne at joda.org>
  Date: Wed, 24 Jan 2018 18:36:42 +0000
  Subject: Re: [tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change

  [quoting me}:
  | > 99.9999% of people (not being zic) should really be ignoring those
  | > files,

  | This hasn't been true for many many years. The source files are parsed
  | by every downstream program I know.

You mean that firefox parses the source tzdb files?   That's interesting,
I never knew that.  I assume it is a "downstream program you know [of]"
and it certainly processes times (and java, or at least, javascript, and
yes, I know they are different things).   Are you sure, or were you just
grandstanding?

  | Its been discussed before as to why this is.

Being discussed does not make it agreed.   Or rational.

  | I'd strongly suggest accepting that the source files are
  | a primary interface, which is why negative SAVE values matter to
  | downstream users.

And that makes no sense at all - if you were really parsiong the
tzdata source files, and doing it rationally, you'd be able to handle
negative save values with no problems at all.  The tzcode does.  Other
parsers (as much as I disagree with some of them even existing) have
reported handling them as well.   It is nothing to do with the source
format that (seems to) be a problem with negative SAVE, but just the
sloppy, lazy, way that the CLDR project chose to map from the zone
abbreviations from the tzdb sources to the localized versions.

That problem would exist if you were (more sanely) using the binary
files (which is what I suspect that the applications which use the
buggy code actually do).   The method used is simply wrong.

  | There isn't such a fix - every avenue
  | other than insisting on positive SAVE values will make things worse.

Nonsense.   But before we can discuss ways it can (or could) be fixed
you need to admit that you understand the magnitude of the problem that
you are actually facing.  Negative SAVE is just the tip of the iceberg.

But believe me, I understand the issue with backwards compat.
But this is one time when you might just need to deprecate the old
interfaces and implement new ones - allow the old interfaces to
remain, subject to all of their limitations, and occasional erroneous
results, and when a problem is reported caused by an application
that is doing things the old way, show them how to use the (assumed
non-broken) new interface which actually works.

Whatever ends up happening with negative SAVE, you're eventually going
to have to do this anyway, at least as best I can follow the current
interface (based upon what has been reported here) it is eventually
going to fail cases that you cannot just paper over by altering the
definition of reality in a small (seemingly harmless) way.  Sticking
your head in the sand now is just going to make for a bigger problem
later.

  | Want to make things truly better? Agree to move TZDB under the
  | auspices of CLDR, so it can be managed by a paid team who actually
  | understand stability and compatibility,

You mean the team that somehow came to believe that the tzdata source
format was something they should rely upon?   That would be insane.

You do realise that this (tzdata) is just a collection of data, it is
all public domain, there is nothing stopping this great CLDR team of
professionals from collecting the same data (you can take as much as you
like from the tzdb files, now and in the future) and creating your new
stable wonderful format, that you can rely on forever.

That is, you do not need permission from anyone here to simply do
what you claim that you want to do.

That might (if you design a new source format that better meets your
needs than the tzdb source file format does) make life easier for you,
but by itself it won't fix the problems that need to be solved before
the CLDR localized zone name (abbreviations, and long forms) problems
can be fixed.

  | TZDB is not the centre of the universe. It is a small cog in a much
  | bigger machine. Its time to accept that.

Huh?   Of course that's correct, no-one ever claimed otherwise.
Where did that red herring come from, and why?

kre