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

"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.



Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Reply via email to