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@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@Keystone-Software.com http://www.Keystone-Software.com