On Wed, Apr 27, 2022 at 06:08:44PM -0400, David T. Lewis wrote:
> 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.
> 

I should note also that the current behavior of DateAndTime>>offset:
goes back to Squeak 3.7, so I would expect some compatibility concerns
when we change it, and the unit tests will need to be tweaked.

Dave