[squeak-dev] trunk thinks its tomorrow

David T. Lewis lewis at mail.msen.com
Thu Feb 18 03:21:57 UTC 2016

On Wed, Feb 17, 2016 at 06:49:03PM -0800, Bert Freudenberg wrote:
> > I committed a more invasive ???fix???. Looking forward to your overhaul!
> Btw, I discovered that utcMicrosecondClock differs from primPosixMicrosecondClockWithOffset - the VM must use a different way to get its time. I worked around that by not using the non-offset prims at all, but it may lead to problems.
> In any case, the image now automatically uses the OS???s time zone as reported by primPosixMicrosecondClockWithOffset. To make the tests green I had to make TimeSpan comparison more lenient (treating defaultOffset as wildcard). Basically, if a Date has no timezone set then it will match a Date in any time zone as long as they ???look??? the same. Possibly a better idea would be to have different classes for dates with and without timezones, but then that may be even more confusing.

I think that all we really need is a clear definition of whether DateAndTime
represents local wall clock time, or location-independent time. I think that
it needs to represent location-independent time, and that we should define
it as such. The instance variables in DateAndTime make this a bit obscure,
but if the value of the absolute time and the value of the local time zone
offset are kept separate, it becomes less confusing. That is what I tried to
do in http://wiki.squeak.org/squeak/6197

> I did not remove the timezone handling in Locale startup yet, although it is useless now.
> - Bert -

This looks good to me.

I like the automatic time zone offset update in DateAndTime>>now.

For primPosixMicrosecondClockWithOffset, we probably should have fallback code
that calls <primitive 135> primMillisecondClock for VMs that support only the
original millisecond clock primitive.


More information about the Squeak-dev mailing list