Hi Sean, On 8 April 2018 at 15:32, Sean P. DeNigris <[email protected]> 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
