<tt><font size=2>> <br>>   | The goal of CLDR is to provide names that people in a locale<br>>   | can reasonably understand - and standard/daylight<br>>   | names requires that people can distinguish one from another.<br>> <br>> Why?  What is the motivation for that?<br>> <br>> In real life, I see just the opposite - for better or worse, I get<br>> to see a fair amount of US sport on TV, and during that (never to<br>> ignore a commercial opportunity) there are often ads for other<br>> programs (which are generally not available here...) and from what<br>> I can see they are always advertised as being at 9 ET / 8 CT<br>> (or whatever) - that is, just "eastern time" with no mention<br>> of an S or a D.<br>> <br>> "Why would that be?"  someone might ask...<br>> <br>> Because in practice no-one cares - all that matters is what time<br>> should a viewer switch on the TV to the relevant channel if they<br>> want to watch.   That is, a sync between the event and wall<br>> clock time.   What offset it happens to be from UTC this week,<br>> and whether it will be the same offset next week, is irrelevant.<br>> <br>> This is not to say that knowing the offsets is useless, there<br>> are applications for that .. it is just that the end user mostly<br>> does not care, and the long/short names don't seem to have any<br>> other use than to be presented to end users.   After all, CLDR,<br>> one application you'd think would make use of the names that<br>> exist (without its versions) doesn't even bother to use tzdb's<br>> names - choosing instead to simply ignore them.   If this<br>> applocation prefers to find some other way, how could be expect<br>> that any other would be different?<br>> <br></font></tt><br><tt><font size=2>That's why CLDR maintains "generic" names,
such as "ET" "CT".</font></tt><br><tt><font size=2>And when someone really need distinction between Standard
or Daylight,</font></tt><br><tt><font size=2>then they would use "EST" "EDT"
etc.</font></tt><br><br><tt><font size=2>So the point is - whether someone wants to distinguish
one from another</font></tt><br><tt><font size=2>if a region uses two alternative offsets within a
year.</font></tt><br><br><tt><font size=2>CLDR "standard" "daylight" name
is used for this use case - and</font></tt><br><tt><font size=2>therefore, they should be different. If such distinction
is not necessary</font></tt><br><tt><font size=2>then CLDR suggests to use "generic" name.</font></tt><br><br><br><tt><font size=2>> The time zone is only mentioned in US ads because
the US is a country<br>> with multipe zones, and with synchronised broadcasts, the clock time<br>> will be different in different regions.  In countries without
that,<br>> there is normally (from my observation) nothing more than the time.<br>> I suspect it is probably like that in Japan too, isn't it?<br>> <br></font></tt><br><tt><font size=2>Right. Majority of countries in the world use only
a single offset for</font></tt><br><tt><font size=2>each, and it's not common convention to put zone label/name
along with</font></tt><br><tt><font size=2>time.</font></tt><br><br><tt><font size=2>> That is why I asked for an example of something
real, where the<br>> timezone information is actually used for some real practical<br>> purpose (just displaying it because we have it does not count.)<br>> <br></font></tt><br><tt><font size=2>The "generic" names are introduced after
standard/daylight in CLDR.</font></tt><br><tt><font size=2>Library code like JDK does not support such concept.</font></tt><br><br><tt><font size=2>Because APIs in JDK and ICU (and some others) implements
"parse"</font></tt><br><tt><font size=2>function, and there are not a ignorable numbers of
consumers depending</font></tt><br><tt><font size=2>on round trip capability of date formatting function,
these libraries</font></tt><br><tt><font size=2>need distinction between standard time and daylight
saving time.</font></tt><br><tt><font size=2>(I know this is fragile, and consumer cannot expect
it's always</font></tt><br><tt><font size=2>roundtripable.) But if such feature exists for number
of years,</font></tt><br><tt><font size=2>we cannot simply break this silently, as a library
provider.</font></tt><br><br><tt><font size=2>> So far (and I know it has not been very long)
there has been nothing.<br>> <br>>   | "generic" name is not in TZ db database.<br>> <br>> You're right, it isn't, and perhaps should be.   For all<br>> zones, the relevant (English) string is probably "Time"<br>> (abbreviation, "T").<br>> <br>> kre<br>> <br></font></tt><BR>