Ton Voon wrote: >server's timezone to CET. Dodgy concept there. It really doesn't make sense for a server as a whole to have a default timezone other than UT. A timezone choice is a feature of certain types of application data, not a feature of where you run the application.
>I can understand the arguments about EST, but if there's no ambiguity >about CET, We just found an ambiguity about CET: does it include the DST rules? Also, consider that your form of CET, with European-rules DST, is only defined for 1977 and later (when the EU DST rules are defined), so it falls apart if you need to process earlier times. For those applications you're forced to distinguish between Europe/Paris, Europe/Berlin, and the others. Not to mention that countries went onto CET-with-DST at different times. If you have some definite idea about what "CET" means in your application context, go ahead and implement it. That might be an alias to Europe/Berlin, or a fixed offset from UT, or a synthetic timezone (with its own tzfile) that doesn't match civil time anywhere. But be aware that it's not universally meaningful, and do it at the application level without gumming up the implementation for everyone else. > I note that EST, MST >and HST are supported timezones: Historical oddities. Not role models. -zefram
