Hi Paul I agree and instead of patching the current system I would start using TDD to design a new Date package.
stef On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <[email protected]> wrote: > I think #= is a bad selector for Date and should be avoided when determining > whether something happens on a date, or whether two dates are the same. We > all know March 24th in London covers a different 24 hours than March 24th in > Hawaii but Date>>#= does not. > > > > I think whats needed are more descriptive selectors like > > > Date>>#isSameOnDateAs: aDateOrDateAndTime > Date>>#overlapsWithDate: aDate > DateAndTime>>#occursOnDate: aDate > DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey > DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey > > and change Date>>#= to #shouldNotImplement. > > > FWIW I also don't like #offset: as before you send it you know the timezone > and after you may let that knowledge be forgotten. Real offsets can change > as laws change. > > > > I think people are aware of this but if you have need for comparing dates & > times then you must use a library that accesses the regularly updated Olson > timezone database on your system and classes that respect time zones. Time > zones are political, and legal definitions of offsets can change hours > before the DST transition dates & times. > > > I don't think it matters which default timezone you pick for the image if > you're not going to take them into account when doing comparisons. > > > Unfortunately there isn't a way to avoid this complexity until DST goes > away. > > > There's certainly flaws to how we currently do it and I think > TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked > at Chalten but would guess its good too. > > > > > > > > > Sean P. DeNigris 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? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >
