This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: java.util.Timer not handling negative System.currentTimeMillis()
- From: Andrew Haley <aph at redhat dot com>
- To: Martin Egholm Nielsen <martin at egholm-nielsen dot dk>
- Cc: java at gcc dot gnu dot org
- Date: Fri, 25 Nov 2005 10:47:28 +0000
- Subject: Re: java.util.Timer not handling negative System.currentTimeMillis()
- References: <dlhkm9$t7o$1@sea.gmane.org>
Martin Egholm Nielsen writes:
> I just encountered a funny (initially strange) problem arising because
> my embedded RT-Clock was set to the year 1909.
> Hence System.currentTimeMillis() returns a negative number, and this is
> used internally in java.util.Timer#schedule(), and throws an unchecked
> exception - aarghh...
>
> I know this is an obscure problem, but is there is requirement that we
> are only "allowed" to run gcj on targets with clocks > 1970.
> One could change the Timer code to handle this situation, or just ignore it.
>
> For now I will just make sure the time is not less than 1970 and larger
> than some other limit overflowing the long.
>
> The problem arises because my target's RTC comes with an undefinded
> initial time - hence anything is possible :-)
This is a tricky one, because even if we fix gcj to allow this I
suspect some user code will be confused. It is perhaps not
unreasonable for a programmer to assume that the "current time" during
a program's execution will not predate her birth!
You need to make sure that your RTC is initialized to some sane value.
Having said that, however, it's not clear to me that the line
if (time < 0)
throw new IllegalArgumentException("negative time");
serves any useful purpose.
Andrew.