Markus wrote:
The time zone string CET or MET is never parsed by any software, because in all applications (e-mail, news, etc.) the time format standards require that a numeric local time - UTC offset is also provided (e.g., required by RFC822 except for US names) and the numeric value is then used. Therefore, MET->CET is no compatibility problem.
That seems quite reasonable. A formal scheme is what I expect when handling time zones (myself or by application).
Consequently: Only humans have to recognize the time zone abbreviation and it definitely does not make sense here to use one that does not follow common practice (Langenscheid, PTB, SkyTV, CNN, etc.).
That's the point, humans should be provided a user-friendly naming scheme. But I cannot second your conclusions. The US time zone "names" are very strange (to me!), but I don't care - it's not my domain, I have not to use them. CNN, etc. is not what I would call common practice; in DE I hear the terms MEZ (or MET). I am not talking with the PTB, nor do I inform myself by US broadcasts. Talking about i18n: are these TZ "names" really considered a matter of international standards ? Concerning computer variable TZ, I doubt it. Concerning the definition of an international standard, I do not think that the current 3-letter TZ "names" serve for i18n-"codes"; they are neither formal nor intuitive. As posted some weeks ago, ambiguities and coincidences happen to exist, too. The Olsen DB as a quasi-standard on computers shall fulfill demands of an IS ? To come back to the user-friendliness: the three letter "names" are easily misinterpreted (from a global view); I would prefer something intuitive. Janis