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@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