Re: java.util.Timer not handling negative System.currentTimeMillis()

[Martin Egholm Nielsen <martin at egholm-nielsen dot dk>]

>  > 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.
Now, that's the hole key issue: "Sane" is not necessarily 1970+ for one 
that doesn't bother about the absolute time, but just wants to do 
something in relative time...

> 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.
It's nice fact stated through an exception! :-)
Without having studied the implemented, I reckon removing this would 
probably work with negative times, as well.

// Martin