Hi Sven, On Tue, Apr 10, 2018 at 7:33 AM, Sven Van Caekenberghe <[email protected]> wrote:
> > > > On 10 Apr 2018, at 16:13, Stephane Ducasse <[email protected]> > wrote: > > > > What is a field based date and time? > > This is more of an implementation choice but it has probably influence on > the API as well. > > Field based date/time/datetime objects are like the naive implementation > where each element that we talk about as humans has its own instance > variable. You would store hours, minutes, seconds, nanosecond separately, > as well as year, month, day. > > This is not as efficient as the current implementations, where time is > typically stored as seconds and nanoseconds, and dates as a single julian > day number. > > Still, these are implementation choices. For example, the split between > seconds and nanoseconds is a bit artificial as well (it is so that both > remain SmallIntegers in 32-bit), while in 64-bit this decision could be > revised. > Note that the VM provides times as either 64-bit LargePositiveInteger microseconds from 1901 (32-bits) or 61-bit positive SmallInteger microseconds from 1901 (64-bits), in either UTC or the current time zone. This gives us the following fit-for-purpose limits: DateAndTime fromSeconds: 1 << 64 - 1 // 1000000 586455-01-18T08:01:49-07:00 DateAndTime fromSeconds: SmallInteger maxVal // 1000000 38435-08-17T21:30:06-07:00 Choosing 64-bit nanoseconds doesn't work nearly as well; we run out of bits in 586 years. I don't buy the performance issue of keeping things as SmallIntegers. There is good 64-bit positive integer support in all the 32-bit VMs (e.g. in the interpreter, inlined #+. #- et al all work on a 64-bit integer range). If Pharo does decide to change the internal representation then I suggest that it uses the same representation as the VM. > > On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo > > <[email protected]> wrote: > >> > >> 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 > >> > > > > > -- _,,,^..^,,,_ best, Eliot
