[tz] Acronyms - localization - more CLDR failures
tobias.conradi at gmail.com
Wed Apr 3 10:29:05 UTC 2013
On Wed, Apr 3, 2013 at 12:56 AM, Derick Rethans <tz at derickrethans.nl> wrote:
>> I disagree. I think it's natural to want to abbreviate, especially
>> with things that are repeated a lot.
> But that has to be done in a localized way anyway.
With the default local being English in the IANA time zone database.
> In the Netherlands,
> nobody uses CEST or CET, but rather MEZT and MET...
And CLDR does not even have MEZT and MET for the Dutch language as you
claim is exclusively used in the Netherlands:
> but the tz database
> doesn't have those either. The localization and naming is done very well
> in CLDR.
Counter evidence (Failure on Mexico / Tiempo del Pacifico) has been shown.
> I have implemented the Date/Time support (utilizing this
> database) in PHP, and have given many presentations about the subject.
Ever in front of Mexicans showing Spanish localization for Mexico or
in front of Dutch speakers showing Dutch localization for Central
> always hammer in two things: .... never
> rely or use an abbreviation for anything.
Why not? CET in the context of Europe always refers to "Central
European Time", doesn't it?
Same may go for WAT in Africa and West Africa Time.
As seen with AxT representing AxST/AxDT in Australia, the acronyms are
not all usable in the IANA time zone database, but duplicating
information and inventing new IDs like Europe_Central (=CET),
America_Pacific (US and CA = America?) as is done in
seems like creating a field for having more bugs.
Let's check Shanghai:
In mainland China standard time is called Beijing Time (北京时间)
https://www.google.com/search?q="北京时间" ~ 57 mio results
中国 = China
https://www.google.com/search?q="中国时间" ~ 1 mio results
https://www.google.com/search?q="中国标准时间" ~ 230 000 results
<standard>China Standard Time</standard>
<daylight>China Daylight Time</daylight>
No acronyms at all!
Rheinsberger Str. 18
More information about the tz