RE: user.timezone property

[David Holmes]

Steven Augart writes:
> I've noticed that more than one VM defines a user.timezone property.
>
> Does anyone know where this is officially documented?  The string
> "user.timezone" does not appear anywhere in the Sun 1.4.2 API
> specification.
>
> I'm not sure whether we need to provide it, and if so, what the format
> should be for it.

We seem to be treading similar paths. :) I discovered user.timezone in the
Timezone code and just assumed that this was the simplest way to set the
timezone information.

I fill in user.timezone during insertSystemProperties at the same time as
all the other dynamic properties that have to be obtained from the OS: file
encoding, user name, os name, current dir etc etc.

Under POSIX the tzset() library call is used - though it is somewhat odd
that the required information relies on the system supporting the OSI
extension to POSIX. POSIX mandates the required format of the TZ environment
variable, which is stdoffset[dst [...]] and  std == tzname[0] while dst ==
tzname[1], but offset is only available as a global int value if using
supporting the OSI extensions.

The native code with classpath seems to have a bug in it though because it
ignores tzname[1] when it is different to tzname[0] rather than when it is
the same.

I have a "native" getDefaultTimeZoneId() method but it just returns null
because if I couldn't figure out the timezone when setting user.timezone,
I'm not likely to be able to figure it out later.

> Maybe we don't need user.timezone?  Does anyone know of any programs
> that actually use it?

My feeling is that user.timezone is not a property that is filled in for use
by application code, but rather for one part of the VM to communicate
indirectly with another part. I think the file.encoding property acts
similarly.


David Holmes