> On 9 Apr 2018, at 08:51, Max Leske <[email protected]> wrote: > > Hi Sean, > On 8 April 2018 at 15:33:11, 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 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.
Right now, a Date is defined as a timespan of 1 day starting from a precise point in time (a DateAndTime with an offset). The fact that it is more advanced is hidden behind a simpler (too simple) API. I think most people think of a Date as a AbstractJulianDate with three components: year/month/day that they want to interpret in there own way (in there own timezone). I would not call that an UTCDate, although that would be one interpretation of the abstraction. I don't think there is an easy/universal solution. > Cheers, > > Max > >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>
