> > 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.

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

It's a complex domain topic, there's no avoiding some confusion at times.

> implemented UTCDateAndTime for Squeak.
>
>   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
it.

Is yours the same API as Chronology but just the different
implementation?  Are there any backward compatibility issues?