[squeak-dev] Some failing tests in Squeak5.2alpha
David T. Lewis
lewis at mail.msen.com
Wed Jun 20 05:51:55 UTC 2018
On Tue, Jun 19, 2018 at 06:07:07PM -0500, Chris Muller wrote:
> > > The everlasting debate is about the time zone. Some say it is UTC, others
> > > say it is whatever time zone you're in. The test is failing, because it
> > > expects the value for UTC, while the method it uses (#asSeconds) was
> > > changed to use your current time zone.
> Right or wrong, the DateAndTime's #epoch has always been defined in
> terms of the local time, not GMT. Until the "change" you mentioned (I
> call it a fix), #asSeconds would report a different value for the same
> exact DateAndTime instance depending on the timezone the client image
> was running in. Now, it doesn't.
Well, not quite always.
The implementation of the Smalltalk epoch is Squeak is, and always has
been, wrong. As near as I can determine, it resulted from some very early
corner-cutting in VM development that may have seemed reasonable at the
time, but is nevertheless wrong.
Eliot claims to have archival evidence of the definition of the "Smalltalk
epoch" that does not assume local time. This is less well documented than
we might like (after all, you cannot Google it), but at least it is not
You cannot hack your way around this forever. At some point, you must
at least agree on a definable reference point for the epoch. This is
simply not possible with a Smalltalk epoch defined in local time.
> It seems we all want a time-zone independent epoch, couldn't we define
> #utcEpoch to do that. The distinct name would clarify whatever
> expectations people had on this matter. Probably we could switch
> #asSeconds to use it, but we should be careful...
> > Putting an end to this kind of endless confusion is the reason that I
> > implemented UTCDateAndTime for Squeak.
> It's a complex domain topic, there's no avoiding some confusion at times.
I think it should be less confusing.
> > http://wiki.squeak.org/squeak/6197
> > http://www.squeaksource.com/UTCDateAndTime/
> > Back when I did this in 2014, I considered it experimental. But after four
> > years of use, I cannot think of any good reason not to adopt it in trunk.
> > Maybe we can discuss some time after the 5.2 release.
> I also did as well in 2004, called "Ma time objects", with one
> LargeInteger representing the number of milliseconds from the epoch to
> represent a unique point on a timeline. It seemed efficient at the
> time, but those LargeIntegers sort of bogged down space and
> computation relative to Chronology (which has an Array, but no
> LargeIntegers), plus compatibility with Squeak objects, so I abandoned
> Is yours the same API as Chronology but just the different
> implementation? Are there any backward compatibility issues?
As far as I can tell, there is no inefficiency either in memory or
in speed. The UTCDateAndTime variation is overall about twice as
fast as the current implementation in Squeak, both for Spur and for
the old V3 format.
Yes the api is the same.
There are some backward compatibility issues. These are identified in
a small number of unit tests that fail, and that probably should fail
until we figure out what the right semantics should be.
Deserializing from ReferenceStream has been handled, but MA serializer
and Fuel serializer have not been addressed.
More information about the Squeak-dev