[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.

http://wiki.squeak.org/squeak/6197

Date

> Pharo's DateAndTime is not the same as Squeak's.
>
> We are properly UTC based/aware, see #secondsSinceMidnightUTC and
> #julianDayNumberUTC.
>
> 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:
>
>> From
>> http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4760319.html
>> :
>>
>>
>> David T. Lewis 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
>>>
>>>
>>>
>>>
>>>
>>> UtcDateAndTime-dtl.sar (40K)
>>> <http://forum.world.st/attachment/4760319/0/UtcDateAndTime-dtl.sar>
>>> LXTestDateAndTimePerformance.st (2K)
>>> <http://forum.world.st/attachment/4760319/1/LXTestDateAndTimePerformance.st>
>>
>>
>>
>>
>>
>> -----
>> Cheers,
>> Sean
>> --
>> View this message in context:
>> http://forum.world.st/Fwd-A-UTC-based-implementation-of-DateAndTime-tp4774975.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>
>






More information about the Pharo-dev mailing list