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

Robert Elz kre at munnari.OZ.AU
Fri Jan 26 18:09:13 UTC 2018

  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

  | 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

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

  | 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.


More information about the tz mailing list