Sven
long time ago I was believing that this is important to have a nice and
rich model for the core but on dates/calendars it is complex so
what I would do is to have a small and working code for Date/ and make
sure that more complex model can be loaded by people.
Stef
On 27/8/14 12:02, Sven Van Caekenberghe wrote:
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.
