<div dir="ltr"><div><div><div><div><div><div>Hi Dave,<br>did you lurk at the work in Pharo?<br></div>I think they followed similar approach, but they kept jdn seconds and nanos, representing time in UTC, and they used UTC clock exlcusively.<br>
</div><div>It would be interesting to compare the timings vs latest Pharo (3.0).<br></div><div><br></div>A single variable is interesting for simplifying implementation.<br>I wonder about the required precision though...<br>
There are about 2^20 microseconds in a second, and about 2^31 seconds in about 68 years.<br></div>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.<br>
</div><div>That seems well enough, considering that second precision for an event several centuries ago is sufficient.<br></div><div>And with the avent of SmallDouble in 64 bits Spur, that would be certainly more efficient than now.<br>
</div><div><br></div>But nanos would cost 10 more bits and be rapidly out of reach (with a span of +/- 3 month around the epoch)...<br></div>I'm afraid that using a Fraction (ScaledDecimal) be an efficiency killer, but I didn't measure anything...<br>
<br></div>Nicolas<br><div><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-19 4:42 GMT+02:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have been experimenting with a new implementation of DateAndTime based<br>
on a UTC magnitude. In this implementation, the instance variables jdn,<br>
seconds, and nanos are replaced with a single utcMicroseconds, and the<br>
offset (a Duration) is replaced by localOffsetSeconds (an integer). The<br>
UTC magnitude and offset are provided directly by primitiveUtcWithOffset<br>
when doing DateAndTime now.<br>
<br>
I had hoped to achieve a sigificant performance advantage with this<br>
implementation, and while it does improve performance, I am only seeing<br>
about a 10% improvement overall, which is considerably less than I had hoped.<br>
Nevertheless, it is indeed faster, and implemention does have some interesting<br>
characteristics.<br>
<br>
The utcMicroseconds magnitude is in units of microseconds, but it is not<br>
required to be an integer and may represent time to any precision. In practice,<br>
values are integral unless the instance is explicitly created with a nanosecond<br>
value.<br>
<br>
New instances created by "DateAndTime now" will have the correct time zone<br>
offset as provided by the operating system platform, and their magnitude is<br>
set to a UTC value the precision provided by the platform.<br>
<br>
New instances created by other constructors use TimeZone default, which is<br>
problematic given that the time zone in Squeak may or may not match the<br>
(presumably correct) values provided by the operating system.<br>
<br>
Instances of DateAndTime are (at the moment) considered equal if their magnitudes<br>
are the same, independent of the time zone offset. This makes sense when thinking<br>
of them as magnitudes (DateAndTime is a Magnitude), but saying that two instances<br>
with different local offsets are equal might be wrong in other contexts.<br>
<br>
The localOffsetSeconds is used for displaying the date and time, and is not<br>
related to magnitude. Thus a DateAndTime is both a magnitude (UTC time) and a<br>
formatter (use the offset to show the magnitude in the context of a local<br>
time zone).<br>
<br>
Dave<br>
<br>
</blockquote></div><br></div>