[tz] [english 100%] Re: [english 100%] Re: OpenJDK/CLDR/ICU/Joda issues with Irelandchange
kre at munnari.OZ.AU
Fri Jan 26 07:15:43 UTC 2018
From: Meno Hochschild <mhochschild at gmx.de>
Date: Fri, 26 Jan 2018 05:49:44 +0100
Subject: Re: [tz] [english 100%] Re: [english 100%] Re:
OpenJDK/CLDR/ICU/Joda issues with Irelandchange
| An illustrating example: If the rule line contains an optional
| meta-column at the end whose content is a key-value-structure
| (comma-separated in case of several entries for any other purpose) then
| the Eire-rules might look like this:
Before we spend too much time on this, and considering that we have (well
CLDR has) meta-zones, and you're proposing a meta-column, I have a
Why do we need all this?
That is, what end-user real applications actually use any of this data,
what do they use it for, and what do they really need (or want) ?
Now I know why (I suspect) all of us here need it - we need it because
we have to comply with the POSIX APIs, and for historic reasons coming
from 1970's vintage (US centric) unix, those APIs have time zone
abbreviations, and tm_isdst, and stuff like that.
So, the tzdb project has to provide the data that POSIX demands that
applications be able to use.
Simililarly, tzdb is all English (to which the "english 100%" which appears
multiple times in the Subject of these messages refers) and that's
not acceptable to international users, so CLDR provides the information
in languages, and character sets, that are more suitable to people in
places where "English 100%" is more like "English 1%"...
All that is understandable, there is a need, and we happen to be the
groups that fill that need.
Given that, it can sometimes be hard to even contemplate, let alone
accept, that all of this hard work, which we must perform, might simply
be wasted, and of no real interest to anyone or anything important.
So before we waste a lot more time designing fixes to this problem
(which would mean enhancing CLDR to allow more than 2 non-generic
names for a timezone, and all their users to fix their code to handle
that) can we find out whether there is any point to all of this.
There are two answers that are not interesting...
1) our test suite tests it, so we need to make it work before we can
release new versions... (the test suite can be altered.)
2) we display this in our UI. Why? Because it is available. If
you stopped displaying it, would it matter? Users would notice the
difference and complain. Would it actually affect how your application
works, or how the users use it? Not really, no.
If (2) there ends with a "yes" answer, then exactly how the data is used,
what its needed for, and what would break without it (this is assuming
it is all working perfectly, ignore what happens if things change and
cause errors, for now anyway) is what would be useful to know.
Maybe it will turn out that all of this really is important (to at
least some class of end users and the apps they use) in which case we
need to go ahead and find solutions to the problems that are known to
exist now. I don't think I have ever seen one. Ever. But of
course, I don't have experience with *everything* that exists (nor
even most of it) so I might just have missed something, somewhere.
But if not, a better solution would be to get posix to simply (even more)
deprecate all the old trash, so we don't have to provide it, and all of
us can go back to doing work that actually provides a useful service
rather than wasting lots of time looking for solutions to problems that
no-one really cares about.
More information about the tz