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
|