What is missing in the current Pharo image is a field based Date/DateTime instead of an offset+duration one as it currently is.
Why not use Chronos instead? AFAIR Chronos provides that. An alternative would be to implement a "Calendar" (as in Java.util.Calendar [1]), that can exist in parallel with the existing Date class. Regards, [1] https://developer.android.com/reference/java/util/Calendar.html On 10/04/2018 03:30, Stephane Ducasse wrote: > 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 >> > -- Esteban A. Maringolo
