[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: user.timezone property
From: |
Mark Wielaard |
Subject: |
Re: user.timezone property |
Date: |
Fri, 30 Apr 2004 20:09:10 +0200 |
Hi,
On Wed, 2004-03-24 at 12:32, Steven Augart wrote:
> David Holmes wrote:
> [...]
> > 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.
>
> Jikes RVM sets those in "runrvm", a shell script that calls the actual
> C executable.
>
> [....]
> > 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.
>
> Yes, I see it too. I should get the rest of my night's sleep and then
> think about a test case to manifest the problem.
Most probably to late for 0.09. But did anybody look more into this
and/or make a test case? (BTW, please but such things in the savannah
bug database also.)
> [....]
> > 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.
>
> This makes sense, yes. Now I know why I want to set it; my test
> program that calls TimeZone.getDefault().getDisplayName() always
> prints "Greenwich Mean Time" if I don't.
Hmmmm. We probably should provide a convenience native function to set
it when the runtime doesn't set it. That is actually what the
getDefaultTimeZoneId() should do, but from the above I assume it is
broken.
Sorry for not picking this up earlier.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: user.timezone property,
Mark Wielaard <=