Date classes

David T. Lewis lewis at mail.msen.com
Wed May 2 02:58:50 UTC 2007


On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote:
> Keith Hodges wrote:
> >J J wrote:
> >>I have looked at Cronos but it is really huge, and the classes that 
> >>come with the image are already very close.  I will have to look at 
> >>Chalten, but what is wrong with a few upgrades to the classes that 
> >>come with Squeak?
> >Absolutely nothing, the squeak classes recently had a fairly 
> >comprehensive rewrite, and are still essentially a 1.0 release, it 
> >should be expected that some updates and improvements are desired. There 
> >is plenty of room for these base classes to evolve. For example I would 
> >also propose a split in the packaging of these classes so there can be 
> >an absolute minimum Kernel version for KernelImages as well as a fully 
> >featured version.
> 
> 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.

Dave




More information about the Squeak-dev mailing list