On Tue, May 01, 2007 at 08:57:19PM -0700, Andreas Raab wrote:
> David T. Lewis wrote:
> >On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote:
> >>I have been experimenting with this idea recently and the bottom line is 
> >>that all you *really* need is access to the millisecond clock primitive 
> >>(for Delay and friends). Pretty much everything else can be built on top 
> >>of that without access to more elaborate Date and Time classes. Moving 
> >>#millisecondClockValue into, say, Delay would make a great starting 
> >>point to rip out all of the Chronology classes for a minimal image.
> >
> >This is true if and only if the millisecond clock is a monotonically
> >increasing function. That is not the case for the Squeak VM, which
> >presents a "local time" version of the clock. Thus for example durations
> >that cross daylight savings time transitions are problematic. If we
> >change to a millisecond clock that represents UTC time rather than
> >local time, then you are absolutely right.
> 
> I'm not getting your point. Why is having a monotonically increasing 
> msecs clock a requirement? What I meant to say is that the only 
> dependency I can't think to get rid of is the millisecond clock and only 
> because it's tied so intrinsically to Delay which itself is tied 
> intrinsically to Semaphore and Process. Which, even for a minimal image, 
> you probably can't get rid of ;-) But it seems to me that whether the 
> msecs clock is monotonically increasing or not is independent of that.

You are absolutely right with regard to the dependencies. My only
point is to clarify that the existing Squeak millisecond clock is
not sufficient for getting the rest of it right. But as you say
this is independent of your argument.

Alan Lovejoy gives a better explanation of the issue in his reply.
It's important because, without a correct implementation, things
like time durations can look like they are correct but in fact
will not be right under certain circumstances. For example, if
you schedule a ten minute delay beginning at 1:55am, and a Daylight
Savings Time transition happens to occur five minutes later, the
delay may not do what you intended.

FWIW, I had to deal with this when implementing TimeZoneDatabase.
It is not trivial to figure out "DateAndTime now" based only on
the information from the millisecond clock if the time happens
to be two and a half hours after midnight on the day of a fall
Daylight Savings Time transition. It can be solved, but you
have to keep track of whether or not a DST transition has
already occurred. The unit tests illustrate the problem and
the (rather awkward) solution.

Dave