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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
