Fwd: A UTC based implementation of DateAndTime
Locked
Fwd: A UTC based implementation of DateAndTime
 
Administrator
|
From http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4760319.html :
Cheers,
Sean |
Re: Fwd: A UTC based implementation of DateAndTime
|
|
Nice.
Could be named ZDateAndTime :P Esteban A. Maringolo 2014-08-26 20:10 GMT-03:00 Sean P. DeNigris <[hidden email]>: > 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. > |
Re: Fwd: A UTC based implementation of DateAndTime
|
|
In reply to this post by Sean P. DeNigris
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 <[hidden email]> 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. > |
Re: Fwd: A UTC based implementation of DateAndTime
|
|
Yes, Cami made a lot of great work on making DateAndTime UTC based.
Cheers, -- Pavel 2014-08-27 12:02 GMT+02:00 Sven Van Caekenberghe <[hidden email]>: > 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 <[hidden email]> 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. >> > > |
|
|
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> 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. >> > > > |
Re: Fwd: A UTC based implementation of DateAndTime
|
|
Sure, I am not suggesting to add anything, I was just commenting on the fact that Date does indeed sometimes act a bit unexpected.
On 27 Aug 2014, at 16:56, stepharo <[hidden email]> wrote: > 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 <[hidden email]> 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. >>> >> >> >> > > |
Re: Fwd: A UTC based implementation of DateAndTime
|
|
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> 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. >> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |