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

[Yoshito Umaoka]

> 
>   | The goal of CLDR is to provide names that people in a locale
>   | can reasonably understand - and standard/daylight
>   | names requires that people can distinguish one from another.
> 
> Why?  What is the motivation for that?
> 
> In real life, I see just the opposite - for better or worse, I get
> to see a fair amount of US sport on TV, and during that (never to
> ignore a commercial opportunity) there are often ads for other
> programs (which are generally not available here...) and from what
> I can see they are always advertised as being at 9 ET / 8 CT
> (or whatever) - that is, just "eastern time" with no mention
> of an S or a D.
> 
> "Why would that be?"  someone might ask...
> 
> Because in practice no-one cares - all that matters is what time
> should a viewer switch on the TV to the relevant channel if they
> want to watch.   That is, a sync between the event and wall
> clock time.   What offset it happens to be from UTC this week,
> and whether it will be the same offset next week, is irrelevant.
> 
> This is not to say that knowing the offsets is useless, there
> are applications for that .. it is just that the end user mostly
> does not care, and the long/short names don't seem to have any
> other use than to be presented to end users.   After all, CLDR,
> one application you'd think would make use of the names that
> exist (without its versions) doesn't even bother to use tzdb's
> names - choosing instead to simply ignore them.   If this
> applocation prefers to find some other way, how could be expect
> that any other would be different?
> 

That's why CLDR maintains "generic" names, such as "ET" "CT".
And when someone really need distinction between Standard or Daylight,
then they would use "EST" "EDT" etc.

So the point is - whether someone wants to distinguish one from another
if a region uses two alternative offsets within a year.

CLDR "standard" "daylight" name is used for this use case - and
therefore, they should be different. If such distinction is not necessary
then CLDR suggests to use "generic" name.


> The time zone is only mentioned in US ads because the US is a country
> with multipe zones, and with synchronised broadcasts, the clock time
> will be different in different regions.  In countries without that,
> there is normally (from my observation) nothing more than the time.
> I suspect it is probably like that in Japan too, isn't it?
> 

Right. Majority of countries in the world use only a single offset for
each, and it's not common convention to put zone label/name along with
time.

> That is why I asked for an example of something real, where the
> timezone information is actually used for some real practical
> purpose (just displaying it because we have it does not count.)
> 

The "generic" names are introduced after standard/daylight in CLDR.
Library code like JDK does not support such concept.

Because APIs in JDK and ICU (and some others) implements "parse"
function, and there are not a ignorable numbers of consumers depending
on round trip capability of date formatting function, these libraries
need distinction between standard time and daylight saving time.
(I know this is fragile, and consumer cannot expect it's always
roundtripable.) But if such feature exists for number of years,
we cannot simply break this silently, as a library provider.

> So far (and I know it has not been very long) there has been nothing.
> 
>   | "generic" name is not in TZ db database.
> 
> You're right, it isn't, and perhaps should be.   For all
> zones, the relevant (English) string is probably "Time"
> (abbreviation, "T").
> 
> kre
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180126/0da78073/attachment.html>