Hi Sean, On 8 April 2018 at 15:33:11, Sean P. DeNigris (s...@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 first wanted to fully agree with you but then I had to think back on the times I've had to fight timestamp bugs when working with Pharo and relational databases. A database will make its own assumptions about the offset. From the PostgreSQL documentation ( https://www.postgresql.org/docs/9.1/static/datatype-datetime.html): "For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter, and is converted to UTC using the offset for the timezone zone." Assuming UTC is probably just as wrong as assuming the local time zone. Maybe the problem is more about the interface of DateAndTime, where you don't really have to care about the time zone offset until it bites you. If the interface would force you to specify the time zone, then you'd be aware from the beginning that it's something to take into account. Cheers, Max ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
