RE: TimeZone

[Mark Wielaard]

Hi,

On Tue, 2004-09-07 at 09:55, Jeroen Frijters wrote:
> Mark Wielaard wrote:
> > On Mon, 2004-09-06 at 20:44, Jeroen Frijters wrote:
> > > Upon reflection (and some more experiments) the code doesn't seem to
> > > make any sense to me.
> > 
> > The TimeZone.getDefaultTimeZone(String) should have enough 
> > documentation of how the format is interpreted.
> 
> I think you know my POV on that. IMO we should be compatible with Sun.

Sure if there is at least some specification. It is always nicer to be
compatible. But in this case we have an internal platform dependent way
of "guessing" the correct default TimeZone for a system. There isn't
much to be compatible with in this case.

> > It is derived from (a simplified version of) how POSIX defines this.
> > All VMTimezone implementations arePOSIX/GNU specific at the moment.
> > Is this hard for you to implement in IKVM?
> 
> When I originally looked into it I couldn't figure out how to do it
> properly, but I think the current TimeZone/VMTimeZone split is good
> enough for me. At the moment I simply return GMT[+-]<offset> though.
> This seems to work reasonably (apart from daylight saving).

Correct. If you don't give a (daylight time zone name) ofter the
<offset> and you use the default (package private)
TimeZone.getDefaultTimeZone method then timezone is assumed not to have
daylight saving period ever. As that method explains:

   * A GMT offset is the offset to add to the local time to get GMT.
   * If a (GMT offset) is included (either in seconds or hours) then
   * an attempt is made to find a TimeZone name matching both the name
   * and the offset (that doesn't observe daylight time, if the
   * timezone observes daylight time then you must include a daylight
   * time zone name after the offset), if that fails then a TimeZone
   * with the given GMT offset is returned (whether or not the
   * TimeZone observes daylight time is ignored), if that also fails
   * the GMT TimeZone is returned.
   * <p>
   * If the String ends with (GMT offset)(daylight time zone name)
   * then an attempt is made to find a TimeZone with the given name and
   * GMT offset that also observes (the daylight time zone name is not
   * currently used in any other way), if that fails a TimeZone with
   * the given GMT offset that observes daylight time is returned, if
   * that also fails the GMT TimeZone is returned.

> I can't find it either, but some experimentation shows the following
> formats to be supported:
> GMT[-+]H
> GMT[-+]HMM
> GMT[-+]HH
> GMT[-+]HHMM
> GMT[-+]:MM
> GMT[-+]H:MM
> GMT[-+]HH:MM
> 
> (where H and M are digits 0..9)

Interesting. And how do you specify whether or not (or when) there is a
daylight saving period?
Maybe we should handle translate this user.timezone format to our own
getDefaultTimeZone() format if we can recognize it.

> > 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

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