On Mon, Apr 25, 2022 at 02:17:49PM -0400, David T. Lewis wrote:
> On Mon, Apr 25, 2022 at 09:16:39AM +0200, Marcel Taeumel wrote:
> > Hi Dave --
> > 
> > I presume that we did this for backwards compatibility? How much old code do we suspect is there? I would prefer to make #utcOffset: the default in #offset: and maybe offer #offset: as #setRawOffset:?
> > 
> 
> 
> I was thinking along those lines when I put the "self flag: #FIXME"
> in this method eight years ago.
> 
> But this also part of the ANSI protocol, so we should take a close
> look at the spec before changing the implementation. Maybe a good
> topic to take up after the 6.0 release.
> 
> My biggest uncertainty is what exactly did the ANSI folks mean by
> "equivalent" instances of DateAndTime? The definition that I see
> in the spec is frustratingly vague:
> 
> 	The meaning of "equivalent" cannot be precisely defined but the intent is that two objects are
> 	considered equivalent if they can be used interchangeably. Conforming protocols may choose to
> 	more precisely define the meaning of "equivalent"
> 
> Dave

I need to correct myself here. I said that the ANSI spec is vague
in its definition of "equivalent" instances of DateAndTime. In fact,
the document offers this clarification in the specification for #=
that makes the intention quite clear:

  5.8.1.4 Message Refinement: = comparand
  Synopsis
    Object equivalence test.
  <snip>
  Refinement: <DateAndTime>
    Answer true if the comparand conforms to <DateAndTime> and if it represents the
    same UTC time as the receiver. Answer false otherwise. The local times of the receiver and
    operand are ignored.

For Squeak's DateAndTime this means that two instances are equivalent
if their utcMicroseconds are the same.

That in turn means that our implementation of DateAndTime>>#offset:
is in violation of the spec. So yes it is broken and should be fixed,
although I'm not sure about compatibility concerns for applications
that may depend on the current Squeak behavior.

Whenever it gets fixed, my recent comment update should be reverted.
The original method comment quotes the ANSI spec, and it should do
so again once the implementation is corrected.

Dave

> 
> 
> > Best,
> > Marcel
> > Am 24.04.2022 19:43:02 schrieb commits at source.squeak.org <commits at source.squeak.org>:
> > David T. Lewis uploaded a new version of Chronology-Core to project The Trunk:
> > http://source.squeak.org/trunk/Chronology-Core-dtl.79.mcz
> > 
> > ==================== Summary ====================
> > 
> > Name: Chronology-Core-dtl.79
> > Author: dtl
> > Time: 24 April 2022, 1:42:51.885752 pm
> > UUID: 6f7605b0-2d71-404a-bb89-0a18345f875a
> > Ancestors: Chronology-Core-mt.78
> > 
> > Provide a better method comment for DateAndTime>>offset: to address a long-standing #FIXME flag. We now have #utcOffset: to complement #offset: so a better explanation of the behavior is sufficient to clarify the difference.
> > 
> > =============== Diff against Chronology-Core-mt.78 ===============
> > 
> > Item was changed:
> > ----- Method: DateAndTime>>offset: (in category 'ansi protocol') -----
> > offset: anOffset
> > + "Answer a DateAndTime for a different time zone offset that has the same
> > + year, month, day, hour, minute, and second as this instance, and with
> > + printString that matches except for time zone offset."
> > 
> > - "Answer a equivalent to the receiver but with its local time
> > - being offset from UTC by offset."
> > -
> > | newOffset newMicros |
> > - self flag: #FIXME. "check the definition of this and of #utcOffset:"
> > newOffset := anOffset asDuration asSeconds.
> > newMicros := localOffsetSeconds - newOffset * 1000000 + utcMicroseconds.
> > ^ self class utcMicroseconds: newMicros offset: newOffset
> > !
> >