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

[Robert Elz]

  From: Brian Inglis <Brian.Inglis at SystematicSw.ab.ca>
  Date: Fri, 26 Jan 2018 10:10:07 -0700
  Subject: Re: [tz] [english 100%] OpenJDK/CLDR/ICU/Joda issues with Ireland
    change

  | Embedded devices sold outside the US or native English speaking world,
  | especially the EU, CN; like: mobiles, tablets, e-readers, non-MS servers
[...]

That's just a list of things that would use time and internationalised
interfaces.

That's not at all useful, or even relevant.

What I was asking for is an example of something which uses these
time zone name strings for something that matters.  And what that use
actually is.  That is: a real demonstrated example, not a "well
there must be something" answer.


I live (and have for many years now) in exactly that part of the world,
and I've never seen aything that uses the time zone labels, other than
stuff like the unix date command, which displays the abbreviation, just
because it always has ... not for any particularly good reason.

Certainly (and particularly since it gets shoved in before the year,
scripts that parse the output from date expect it to be there - the
year that follows is clearly useful (even though these days it would
be more common to use date's strftime interface and get values that way)
so we cannot simply delete it - but we could make it always be XXX or
something, and aside from looking a bit ugly, I suspect no-one would
really care.  (Or we could always replace it with the numeric offset
instead, for all zones.)

Once again, someone, point me at something that would actually break
if this was to be done?   We have numeric (+NN etc) values as the
abbreviation in quite a few zones now, and no-one has been moaning
about their applications failing because of it, or not that I have
seen.

  | It's probably easier (and cheaper!) to (un-)patch the tzdb to conform to
  | downstream compatibility requirements, than it would be to change all
  | downstreams to conform to tzdb theoretical requirements, until those
  | capabilities are actually required somewhere in the real world.

That is definitely the wrong approach.  That's the "let's bury our
heads in the sand and hope it never happens" solution - which is
guaranteed to lead to havoc, when (which it seems is really in the past
anyway) it does happen.

Much better to commence the updates now, while there is less time
pressure, and so more time to plan a suitable conversion strategy,
then to just do nothing (for now) and hope.

kre