[squeak-dev] Adding UTCDateAndTime to trunk (was: UTCDateAndTime
updated for Squeak trunk Chronology and Spur (was:
UTCDateAndTime updated for Squeak 4.6/5.0))
David T. Lewis
lewis at mail.msen.com
Wed Jun 22 03:50:36 UTC 2016
I would like to consider offering UTCDateAndTime for inclusion in trunk.
On 64-bit Spur, overall performance is almost twice that of the base Chronology
package. In addition, the representation of DateAndTime as Posix time plus time
zone offset is simpler and easier to test and understand.
I cannot easily put this into the inbox, but loading the package into a trunk
image is done as follows:
(MCMcmUpdater
updateMapNamed: 'update'
repository: 'http://www.squeaksource.com/UTCDateAndTime')
doUpdate: false.
I have not modified any of the Chronology tests. After loading UTCDateAndTime
into a trunk image, here are the tests that will fail, along with my explanation
for the failures:
DateAndTimeEpochTest>>testHash
- DateAndTime>>hash works differently now. Test should be either
updated or eliminated.
DateAndTimeLeapTest>>testAsSeconds
- Discussion required. I claim that #asSeconds can only make sense
if it means elapsed seconds since the epoch. The prior implemention
and the test are both wrong.
DateAndTimeLeapTest>>testHash
- DateAndTime>>hash works differently now. Test should be either
updated or eliminated.
DateAndTimeTest>>testPrecision
- Discussion required. It is simply wrong to assume that two calls
to DateAndTime class>>now will always answer different values, and
it is even more wrong to fudge the clock accessors to make it appear
to be doing this when it is not. Yes I know that certain database
applications require distinct time stamps, but hacking the actual
system clock is not the right thing to do.
TimespanDoTest>>testDatesDo
- Need to change the test setUp method. The original intent is to test
date iteration using a time span begining with a UTC midnight. Test
will pass if the start time is constructed accordingly. Note however
that date iteration is suspect for durations starting at times other
than midnight in the local time zone, so additional tests may be needed.
TimespanDoTest>>testNext
- Same issue as testDatesDo, fix the setUp method and the test will pass,
but additional tests may be needed.
The necessary #primitiveUtcWithOffset is present in all Cog/Spur/interpreter VMs.
It is an optional named primitive (not numbered). If not present, the fallback
code uses the Posix epoch for all new time values, resulting in a runnable image
but with incorrect time stamps for new DateAndTime instances. Falling back to the
original millisecond clock logic and primitives is possible, but it seemed to me
to be an unnecessary complication so I got rid of it.
Does anyone think that adding UTCDateAndTime to trunk is /not/ a good thing to do?
Dave
More information about the Squeak-dev
mailing list
|