Hi, On Tue, 2004-09-07 at 22:13, Mark Wielaard wrote: > > > If there is a real specification then we should translate > > > that to our specification (or adapt our specification and all platform > > > dependend methods that now depend on our specification to the > > > specification of user.timezone, but that is probably much more work). > > > > I don't understand what you mean here. There is only one place that > > parses timezones right? > > No there are multiple methods that try to parse the default timezone of > the platform/system. The vm/reference implementation of
Sorry, didn't finish this sentence. No, there are multiple methods that try to parse the default timezone the platform/system (and then try to get the real TimeZone object through TimeZone.getDefaultTimeZone() based on that). The vm/reference implementation of VMTimeZone tries to parse the platform default timezone through: - Parsing the first line of /etc/timezone - Parsing the /etc/localtime as tz file (normal or "Darwin" format) - Trying to construct a timezone spec format (as TimeZone.getDefaultTimeZone() defines) through native "standard" JNI/Posix C code. > Note that the preferred way of handing a default timezone string to the > TimeZone.getDefaultTimeZone() method is to use one of the Olsen timezone > names (like "Europe/Amsterdam"). If you cannot obtain that name then we > fall back on our own (timezone name)(gmt offset)(daylight time zone > name) format specification as we use in TimeZone.getDefaultTimeZone(). > The reason this isn't prefered is that real time zones have much more > complicated rules then can be expressed in that simple format. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
