Hi Sean,

No.  The recent UTCDateAndTime format change to Squeak made no difference
in this regard.  The example you gave had already been fixed previously by
the introduction of #defaultOffset back in 2012.  Dates created in
non-TZ-specific contexts all get a defaultOffset of 0:00.

So, in your example, '1/1/1901' asDate has no time-specific information, so
it would inherit the defaultOffset (0:00), which compares favorably to
other Dates with the same offset.  Only Dates which were created via:

     myDateAndTime asDate

would inherit the timezone from myDateAndTime, and therefore represent a
different period of time than the ones that began at offset 0:00.

 - Chris



On Wed, Sep 4, 2019 at 11:52 AM Sean P. DeNigris <sean at clipperadams.com>
wrote:

> Did the recent changes to Squeak's Date/Time handling (or any 3rd party
> lib)
> ever solve the following longstanding Chronology bug:
>
>Consider this thought experiment:
> > At 11:59pm before DST changes, eval aDate := '1/1/1901' asDate.
> > Now, wait two minutes and at 12:01am eval self assert: '1/1/1901' asDate
> =
> > aDate and… whammo, an exception!
> > The "different" offsets render equal dates unequal depending on when the
> > objects were created.
> > The fact that the offset is the one active at object creation is the key
> > error, because it should be the offset active when the date occurred.
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190905/01b7314e/attachment.html>