Hi Sean, On 8 April 2018 at 15:32, Sean P. DeNigris <sean@clipperadams.com> wrote:
I was bitten by this very annoying bug again. As most of us probably know due to the steady stream of confused ML posts in the past, the bug in summary is that we have an incomplete timezone implementation that doesn't properly take into account historical DST changes. This flares up without warning especially when DST toggles. I created a wiki page to document the situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
Here's an example blowup: at 11:59pm before DST changes, eval aDate := '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: '1/1/1901' asDate = aDate and⦠whammo, an exception! The "different" offsets render equal dates unequal depending on when the objects were created.
The more I think about it, the more I think that we should just assume UTC for all Date[AndTime]s that don't explicitly specify an offset, rather than pretend to set an offset which is only sometimes correct. More advanced users can use one of the available libraries to get full timezone support. What do you think?
I think using UTC would just move the problem by an hour. As Sven says, the real issue is Date as a timespan vs Date as a d/m/y. What you're doing here is comparing timespans, and one timespan has been moved by 1 hour due to the start of DST. If you did: '1/1/1901' asDate equals: aDate Then everything would be fine. Cheers, Alistair