On Wed, Sep 04, 2019 at 11:52:47AM -0500, Sean P. DeNigris 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.

I would expect that this is no longer a problem. Equality of DateAndTime is
now based on comparing magnitude, expressed as microseconds since Posix epoch,
and independent of time zone offset.

  '1/1/1901' asDate => 1 January 1901
  '1/1/1901' asDate start ==> 1901-01-01T00:00:00+00:00
  '1/1/1901' asDate start utcMicroseconds ==> -2177452800000000
  '1/1/1901' asDate start offsetSeconds ==> 0
  '1/1/1901' asDate start offset ==> 0:00:00:00
  '1/1/1901' asDate duration ==> 1:00:00:00

In other words, if two Date instances start at the same utcMicroseconds,
they will compare equal, regardless of when and where they were created.

All of this should be completely independent of the current timezone offset
for the machine on which it is evaluated.

This does *not* handle the case of a Date for which duration is not
1:00:00:00, as would be the case for a "date" during which a daylight
savings transition occured. This is a conceptual problem resulting from
the definition of a "date" as a duration with a start time and a duration
of 24 hours. The recent changes to Squeak's Date/Time handling do not
attempt to address that problem.

Dave