[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 7 Sep 2004 09:55:12 +0200
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:
(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?