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 <[email protected]> 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. >> > >
