Date classes

Andreas Raab andreas.raab at gmx.de
Wed May 2 03:57:19 UTC 2007


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.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list