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()
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.
> > >
> > > 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?
Andrew.