RE: TimeZone

[Jeroen Frijters]

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.

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

> How did you do this in the previous version of TimeZone 
> (which was even more buggy and broken than the current version)?

Same as now, just the GMT[+-]<offset>.

> >  On the Sun VM, if the abs(offset) is greater than
> > 24 it is interpreted as Hours * 100 + Minutes, instead of 
> the seconds
> > that Classpath uses.
> 
> I haven't found a specification of what user.timezone could 
> actually be set to and how that string is interpreted except
> for the fact that it can be exactly one of the timezone names
> mentioned in the TimeZone documentation.

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)

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

Regards,
Jeroen