<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Dave --<div><br></div><div>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.</div><div><br></div><div>Here is an example:</div><div><br></div><div><span style="font-size: 13.3333px">2022-04-26T08:32:41.69586+02:00 </span><br></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">If I want to change the offset here from +2 to -2, the expected outcome is this:</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px"> 2022-04-26T04:</span>32:41.69586<span style="font-size: 13.3333px">-02:00 </span><br></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">Same point in time but different time zone.</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">Consequently, offering the #offset(:) accessors in a domain-specific way should do this and never break equality check via #=.</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><div style=""><div><span style="font-size: 13.3333px">d1 := DateAndTime fromString: '2022-04-26T04:32:41.69586-02:00'.</span></div><div><span style="font-size: 13.3333px">d2 := DateAndTime fromString: '2022-04-26T08:32:41.69586+02:00'.</span></div><div><span style="font-size: 13.3333px">d1 = d2." true -- correct "</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">d2 := d1 offset: 2 hours. "Same point in time, different time one"</span></div><div><span style="font-size: 13.3333px">d1 = d2." false -- bug "</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">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.</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">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.</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">Just my two cents. :-)</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">Best,</span></div><div><span style="font-size: 13.3333px">Marcel</span></div></div></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 25.04.2022 20:17:59 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">On Mon, Apr 25, 2022 at 09:16:39AM +0200, Marcel Taeumel wrote:<br>> Hi Dave --<br>> <br>> 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:?<br>> <br><br><br>I was thinking along those lines when I put the "self flag: #FIXME"<br>in this method eight years ago.<br><br>But this also part of the ANSI protocol, so we should take a close<br>look at the spec before changing the implementation. Maybe a good<br>topic to take up after the 6.0 release.<br><br>My biggest uncertainty is what exactly did the ANSI folks mean by<br>"equivalent" instances of DateAndTime? The definition that I see<br>in the spec is frustratingly vague:<br><br> The meaning of "equivalent" cannot be precisely defined but the intent is that two objects are<br> considered equivalent if they can be used interchangeably. Conforming protocols may choose to<br> more precisely define the meaning of "equivalent"<br><br>Dave<br><br><br>> Best,<br>> Marcel<br>> Am 24.04.2022 19:43:02 schrieb commits@source.squeak.org <commits@source.squeak.org>:<br>> David T. Lewis uploaded a new version of Chronology-Core to project The Trunk:<br>> http://source.squeak.org/trunk/Chronology-Core-dtl.79.mcz<br>> <br>> ==================== Summary ====================<br>> <br>> Name: Chronology-Core-dtl.79<br>> Author: dtl<br>> Time: 24 April 2022, 1:42:51.885752 pm<br>> UUID: 6f7605b0-2d71-404a-bb89-0a18345f875a<br>> Ancestors: Chronology-Core-mt.78<br>> <br>> 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.<br>> <br>> =============== Diff against Chronology-Core-mt.78 ===============<br>> <br>> Item was changed:<br>> ----- Method: DateAndTime>>offset: (in category 'ansi protocol') -----<br>> offset: anOffset<br>> + "Answer a DateAndTime for a different time zone offset that has the same<br>> + year, month, day, hour, minute, and second as this instance, and with<br>> + printString that matches except for time zone offset."<br>> <br>> - "Answer a equivalent to the receiver but with its local time<br>> - being offset from UTC by offset."<br>> -<br>> | newOffset newMicros |<br>> - self flag: #FIXME. "check the definition of this and of #utcOffset:"<br>> newOffset := anOffset asDuration asSeconds.<br>> newMicros := localOffsetSeconds - newOffset * 1000000 + utcMicroseconds.<br>> ^ self class utcMicroseconds: newMicros offset: newOffset<br>> !<br>> <br>> <br><br>> <br><br><br></commits@source.squeak.org></div></blockquote></div>