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...
>  > > 
>  > > "Sane" in this context just means > 1970.  If you want to work in
>  > > relative time, start at 1970.
>  > Baah! :-)
>  > I'll go with Mark's suggestion! I just need a way to set the date back 
>  > again to pre-1970 - my "date" command does not allow it...
>
> I'm confused.  If you just want to do something in relative time,
> what's wrong with starting at 1970?

I see the confusion... There is nothing wrong with starting at 1970 - if 
you just know you should do so! That's the point - you don't know that 
scheduling a relative task requires the time being 1970+.
1) It should state so in the doc.
2) The exception thrown should indicate that it's not allowed because 
System.currentTimeMillis()+relativeScheduleTime < 0.
3) We accept it's a "bug", and someone (me) sanity checks the code to 
see if we really have to puke at negative times.

BR,
 Martin