Hi Dave --

Well, they can only be used interchangeably if we use the implementation of #utcOffset: in #offset:. If you change the offset of an instance, you must adapt the nanoseconds to keep #= working. That's what the domain prescribes and how I would interpret the ANSI standard.

Here is an example:

2022-04-26T08:32:41.69586+02:00 


If I want to change the offset here from +2 to -2, the expected outcome is this:

 2022-04-26T04:32:41.69586-02:00 


Same point in time but different time zone.

Consequently, offering the #offset(:) accessors in a domain-specific way should do this and never break equality check via #=.

d1 := DateAndTime fromString: '2022-04-26T04:32:41.69586-02:00'.
d2 := DateAndTime fromString: '2022-04-26T08:32:41.69586+02:00'.
d1 = d2." true -- correct "

d2 := d1 offset: 2 hours. "Same point in time, different time one"
d1 = d2." false -- bug "

I think the confusion stems form the fact that the domain-specific meaning of "offset" is somewhat different for the "time" domain. Unlike, for example, drawing offsets in rectangles.

In DateAndTime, #offset is an object property that does not matter in #=. It's like a coordinate/view transformation between elements in a scene graph. Just because one element is rotated 45 degrees clockwise in one view and counter-clockwise in another view makes them still the same.

Just my two cents. :-)

Best,
Marcel
Am 25.04.2022 20:17:59 schrieb David T. Lewis <lewis at mail.msen.com>:
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


> Best,
> Marcel
> Am 24.04.2022 19:43:02 schrieb 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
> !
>
>

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220426/572996e1/attachment.html>