[Pharo-dev] Fwd: A UTC based implementation of DateAndTime
David T. Lewis
lewis at mail.msen.com
Wed Aug 27 12:14:17 EDT 2014
FYI, the UTC based DateAndTime that I did is not part of Squeak.
> Pharo's DateAndTime is not the same as Squeak's.
> We are properly UTC based/aware, see #secondsSinceMidnightUTC and
> It is indeed perfectly possible to represent time using one number, but it
> will not be a SmallInteger. And depending on precision is will be a very
> large number. The split julian day number - seconds since midnight feels
> quite logical and practical to me.
> But yes, the 'date' concept is often confusing and difficult to handle in
> the light of timezones. To me, an old school, abstract Date object
> year/month/day would make sense. But then again, there are so many
> calendar systems, chronology is quite complicated.
> BasicJulianDate ?
> On 27 Aug 2014, at 01:10, Sean P. DeNigris <sean at clipperadams.com> wrote:
>> David T. Lewis wrote
>>> I have been working on a variation of class DateAndTime that replaces
>>> instance variables (seconds offset jdn nanos) with two instance
>>> utcMicroseconds to represent microseconds elapsed since the Posix
>>> localOffsetSeconds to represent the local time zone offset. When
>>> the time now, A single call primitiveUtcWithOffset is used to obtain
>>> two values atomically as reported by the underlying platform.
>>> There are several advantages to this representation of DateAndTime, the
>>> important of which is that its magnitude is unambiguous regardless of
>>> savings transitions in local time zones.
>>> This is my attempt to address some historical baggage in Squeak. The VM
>>> reports time related to the local time zone, and the image attempts to
>>> convert to UTC (sometimes incorrectly). A UTC based representation
>>> implementation of time zone tables more straightforward (see for
>>> the Olson time zone tables in TimeZoneDatabase on SqueakMap).
>>> I am attaching the source code as a SAR file that can be loaded into a
>>> updated Squeak trunk image. The conversion process is slow, so be
>>> if you load it.
>>> This can be run on either an intepreter VM or Cog, but if you use Cog,
>>> use a version dated June 2013 or later (the VM in the Squeak 4.5
>>> is fine).
>>> I am also attaching a copy of LXTestDateAndTimePerformance, which can
>>> used to compare the performance of some basic DateAndTime functions.
>>> Performance of the UTC based DateAndTime is generally favorable
>>> the original. Here is what I see on my system (smaller numbers are
>>> LXTestDateAndTimePerformance test results using the original Squeak
>>> on an interpreter VM:
>>> #testNow->10143 .
>>> #testEquals->30986 .
>>> #testGreaterThan->80199 .
>>> #testLessThan->75912 .
>>> #testPrintString->10429 .
>>> LXTestDateAndTimePerformance test results using the new UTC based
>>> on an interpreter VM:
>>> #testNow->6423 .
>>> #testEquals->31625 .
>>> #testGreaterThan->22999 .
>>> #testLessThan->18514 .
>>> #testPrintString->12502 .
>>> (CC to Brent Pinkney, author of the excellent Squeak Chronology
>>> UtcDateAndTime-dtl.sar (40K)
>>> LXTestDateAndTimePerformance.st (2K)
>> View this message in context:
>> Sent from the Pharo Smalltalk Developers mailing list archive at
More information about the Pharo-dev