"Mark Davis" <mark.davis@jtcsv.com> writes:
http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/tim...
Commenting on the version of 2004-06-11: * The document uses the term "CLDR" without defining it. * 'These translations mark a difference between "generic" usage (aka "wall time") like "Pacific Time" and a fixed offset from GMT like "Pacific Standard Time" or "Pacific Daylight Time", and also allow for both abbreviated and full names.' This doesn't seem to allow for variants in names (e.g. DST in Los Angeles has variously been called "Pacific Daylight Time", "Pacific War Time", and "Pacific Peace Time"). Nor does it seem to allow for double DST. * The document defines "modern" equivalents as those that produce the same result for the current year. More accurate, I think, would be that two zones would have to predict the same results for the current year, the next year, the year after that, etc. In some cases two zones might predict the same results for the current year, but not for next year. * "windows ids shows a mapping from windows IDs to Olson IDs." You might mention that this is a one-to-many mapping, and the Olson ID is chosen somewhat arbitrarily. * "reset of the year" -> "rest of the year" * 'If there is an exact translation, use it. America/Los_Angeles => "Pacific Time"' This example doesn't seem to allow for the case where a city changes time zones. These things happen. (It just happened in Argentina last week.) If you really want a name that means US Pacific Time, you'll need to supply one. Historically the Olson TZID "US/Pacific" served this purpose, but it has been supplanted by geographical IDs partly to avoid ambiguity, partly to avoid controversy. * 'America/Los_Angeles => "Tampo de San Fransisko"' I don't understand this example. Why is Los Angeles being translated as if it were San Fransisco? * "Note that the results are semi-reversible; one cannot necessarily recover the exact time zone that one started with, but can recover a modern equivalent." I don't understand this claim completely, but I'm skeptical. Natural-language time notations are notoriously ambiguous. * "In Mexico one would prefer to see the America/Mexico_City timezone (appropriately localized), while in the US, the America/Chicago one." This is not merely an issue of ease-of-use: it is also important when one wants to specify the desired behavior in the presence of likely future changes. In 2001, the mayor of Mexico City threatened to abolish DST in that city, and the matter remains somewhat controversial, so it's quite possible that the Mexico City and Chicago will diverge in the not-too-distant future. * Some of the document uses notations like "GMT+7" to mean west of Greenwich; some of it uses the same notation to mean east of Greenwich. It should be consistent. I suggest "GMT+7" to mean east of Greenwich. Also, these days it's more technically accurate to write "UTC" instead of "GMT". * At the HTML level the document specifies charset=windows-1252 and the four HTML lines containing non-ASCII characters didn't come out right in my browser. Can you please use plain ASCII instead, e.g., use "«" instead of the Windows-1252 byte that means left-pointing double angle quotation mark? Or it may be simpler to reformulate the examples to avoid non-ASCII characters. * I don't really understand the proposal. Sorry. It's fairly complicated and I don't fully understand the intended use or the motivation. Could be this is because I'm not in the CLDR universe. Anyway, this means I can't really comment on the fundamentals of the document, only on relatively-minor issues like the above.