On Thu, Dec 04, 2003 at 09:00:54PM +0100, Anton Berezin <[EMAIL PROTECTED]> wrote: > > For example, EST is used for "Eastern Standard Time", aka > > America/New_York, but also for parts of Australia. > > > > Even EST in the US is ambiguous, because it's also used for > > America/Indianapolis, a time zone that does not observe DST, in addition > > to America/New_York, which does observe EST. > > > > There's been discussion about this on the list, but I'll repeat this over > > and over. The various 3 and 4 letter abbreviations sometimes used > > colloquially for time zones are often not sufficient to accurately > > determine what the actual time zone is, and should only be used for > > display purposes, as in "January 4, 2003 11:00 EST". > > > > Setting your system's time zone to such a thing is asking for trouble. > > I really don't know. Three-letter abbreviations are POSIX.1. They > might be obsolete, but they are still supported by most implementations, > and used widely.
Umm, a posix-style TZ looks like this: stdoffset[dst[offset][,start[/time],end[/time]]] So at minimum you would have TZ=CET-1 (std and offset). (Note that the offsets are negative east of GMT and positive west of GMT.) If you are using just TZ=CET, I suspect you *do* have an Olson tz entry for CET. Indeed, I see one in tzdata/europe: ># These are for backward compatibility with older versions. > ># Zone NAME GMTOFF RULES FORMAT [UNTIL] >Zone WET 0:00 EU WE%sT >Zone CET 1:00 C-Eur CE%sT >Zone MET 1:00 C-Eur ME%sT >Zone EET 2:00 EU EE%sT It would be nice to have an option to include all the backward-compatibility timezones in DateTime.
