[squeak-dev] Date today versus DateAndTime today

Tim Johnson digit at sonic.net
Fri Apr 22 19:10:16 UTC 2022


> On Dec 9, 2021, at 9:06 AM, Ron Teitelbaum <ron at usmedrec.com> wrote:
> Date is a Timespan while DateAndTime is not. I think we should drop the timezone offset when converting a DateAndTime to a Date. Yet, the class comment of Date reads, that there are rare cases where one would need such an offset. Not sure.
> 
> In my opinion, The result of the comparison should only consider the result of the date with the offset applied.  While it is true that the original date + offset might result in a different date the result should still be true if the resulting dates are the same.  One is the result of the date plus the offset the other is a date but they are both Functionally equal.  The results currently are converting both dates to UTC before the comparison.   
> 
>        self asUTC hasEqualTicks: aDateAndTimeOrTimeStamp asUTC
> 
> That to me is the error.  If you wanted to make that comparison you would do asUTC yourself to remove timezone information.  
> 
> I can not fathom a reason that DateAndTime today asDate = Date today.  is better by returning false.  Anyone worried about timezones in this instance would use UTC or local conversions first before doing the comparison. 

I just found an old 5.1 image where I was playing around with something similar.  

| x c y |
x := TimeStamp now.
c := String streamContents: [:s | x storeOn: s].
y := TimeStamp readFrom: c readStream.
x = y   " => false  "

whereas:

| x c y |
x := TimeStamp now asUTC.
c := String streamContents: [:s | x storeOn: s].
y := TimeStamp readFrom: c readStream.
x = y   " =>  true   "

The difference being that "Timestamp now" has localOffsetSeconds of -25200 (where I live), but this offset is not getting stored via TimeStamp>>#storeOn: (which produces '''22 April 2022 11:48:17.542009 am'' asTimeStamp' ).

I suspect this could be avoided if Squeak were using ISO 8601 formatting for TimeStamp>>#storeOn:   which might capture local time zone info using + or T or something at the end of the string.  But then the code for TimeStamp class>>#readFrom: eventually hits Time class>>#readFrom: which does not support offsets / time zones either.

Reading what Ron wrote above, it seems that the onus is on the user of these classes to remember to use #asUTC, which seems common/best practice...  and avoids unexpected(?) results like the above.

Thanks,
Tim


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220422/4e60430b/attachment.html>


More information about the Squeak-dev mailing list