[squeak-dev] A UTC based implementation of DateAndTime

Louis LaBrunda Lou at Keystone-Software.com
Mon May 26 14:48:16 UTC 2014


Hi Dave,

May I respectfully ask why localOffsetSeconds (to represent the local time
zone offset) is needed?  It seems to me a UTC time is enough.  Is there
really a need for the timezone offset the instance was created in?  Does
every DateAndTime instance need to carry this offset around with it?  I
would think the offset is only needed if one wants to display a date/time
as a local value and then one could get the local offset from the VM or a
program setting the user had previously supplied regardless of where the
computer was setup to run.  I guess there might be some historic interest
as to the timezone an instances (or many instances) was created in but one
could just keep that as a separate value.

Lou

On Sun, 25 May 2014 13:48:44 -0400, "David T. Lewis" <lewis at mail.msen.com>
wrote:

>I have been working on a variation of class DateAndTime that replaces its
>instance variables (seconds offset jdn nanos) with two instance variables,
>utcMicroseconds to represent microseconds elapsed since the Posix epoch, and
>localOffsetSeconds to represent the local time zone offset. When instantiating
>the time now, A single call primitiveUtcWithOffset is used to obtain these
>two values atomically as reported by the underlying platform.
>
>There are several advantages to this representation of DateAndTime, the most
>important of which is that its magnitude is unambiguous regardless of daylight
>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 makes the
>implementation of time zone tables more straightforward (see for example
>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 fully
>updated Squeak trunk image. The conversion process is slow, so be patient
>if you load it.
>
>This can be run on either an intepreter VM or Cog, but if you use Cog, please
>use a version dated June 2013 or later (the VM in the Squeak 4.5 all-in-one
>is fine).
>
>I am also attaching a copy of LXTestDateAndTimePerformance, which can be
>used to compare the performance of some basic DateAndTime functions.
>
>Performance of the UTC based DateAndTime is generally favorable compared to
>the original. Here is what I see on my system (smaller numbers are better).
>
>LXTestDateAndTimePerformance test results using the original Squeak DateAndTime
>on an interpreter VM:
>{
>	#testNow->10143 .
>	#testEquals->30986 .
>	#testGreaterThan->80199 .
>	#testLessThan->75912 .
>	#testPrintString->10429 .
>	#testStringAsDateAndTime->44657
>}
>
>LXTestDateAndTimePerformance test results using the new UTC based DateAndTime
>on an interpreter VM:
>{
>	#testNow->6423 .
>	#testEquals->31625 .
>	#testGreaterThan->22999 .
>	#testLessThan->18514 .
>	#testPrintString->12502 .
>	#testStringAsDateAndTime->32912
>}
>
>(CC to Brent Pinkney, author of the excellent Squeak Chronology package)
>
>Dave
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com



More information about the Squeak-dev mailing list