[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
|