RE: TimeZone

[Mark Wielaard]

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