Hi Sven, On Tue, Apr 10, 2018 at 7:33 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 10 Apr 2018, at 16:13, Stephane Ducasse <stepharo.self@gmail.com> 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 <emaringolo@gmail.com> 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 <pdebruic@gmail.com>
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