Hi Dave,
did you lurk at the work in Pharo?
I think they followed similar approach, but they kept jdn seconds and
nanos, representing time in UTC, and they used UTC clock exlcusively.
It would be interesting to compare the timings vs latest Pharo (3.0).

A single variable is interesting for simplifying implementation.
I wonder about the required precision though...
There are about 2^20 microseconds in a second, and about 2^31 seconds in
about 68 years.
So with a Double, you can span about 4*68 years, in the future of epoch
(same in the past), while keeping the microsecond precision.
That seems well enough, considering that second precision for an event
several centuries ago is sufficient.
And with the avent of SmallDouble in 64 bits Spur, that would be certainly
more efficient than now.

But nanos would cost 10 more bits and be rapidly out of reach (with a span
of +/- 3 month around the epoch)...
I'm afraid that using a Fraction (ScaledDecimal) be an efficiency killer,
but I didn't measure anything...

Nicolas



2014-04-19 4:42 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:

> I have been experimenting with a new implementation of DateAndTime based
> on a UTC magnitude. In this implementation, the instance variables jdn,
> seconds, and nanos are replaced with a single utcMicroseconds, and the
> offset (a Duration) is replaced by localOffsetSeconds (an integer). The
> UTC magnitude and offset are provided directly by primitiveUtcWithOffset
> when doing DateAndTime now.
>
> I had hoped to achieve a sigificant performance advantage with this
> implementation, and while it does improve performance, I am only seeing
> about a 10% improvement overall, which is considerably less than I had
> hoped.
> Nevertheless, it is indeed faster, and implemention does have some
> interesting
> characteristics.
>
> The utcMicroseconds magnitude is in units of microseconds, but it is not
> required to be an integer and may represent time to any precision. In
> practice,
> values are integral unless the instance is explicitly created with a
> nanosecond
> value.
>
> New instances created by "DateAndTime now" will have the correct time zone
> offset as provided by the operating system platform, and their magnitude is
> set to a UTC value the precision provided by the platform.
>
> New instances created by other constructors use TimeZone default, which is
> problematic given that the time zone in Squeak may or may not match the
> (presumably correct) values provided by the operating system.
>
> Instances of DateAndTime are (at the moment) considered equal if their
> magnitudes
> are the same, independent of the time zone offset. This makes sense when
> thinking
> of them as magnitudes (DateAndTime is a Magnitude), but saying that two
> instances
> with different local offsets are equal might be wrong in other contexts.
>
> The localOffsetSeconds is used for displaying the date and time, and is not
> related to magnitude. Thus a DateAndTime is both a magnitude (UTC time)
> and a
> formatter (use the offset to show the magnitude in the context of a local
> time zone).
>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140419/dd4beecf/attachment.htm