TimeZone Check-In
Locked
 
Administrator
|
Did the recent changes to Squeak's Date/Time handling (or any 3rd party lib)
ever solve the following longstanding Chronology bug: >Consider this thought experiment: > At 11:59pm before DST changes, eval aDate := '1/1/1901' asDate. > Now, wait two minutes and at 12:01am eval self assert: '1/1/1901' asDate = > aDate and… whammo, an exception! > The "different" offsets render equal dates unequal depending on when the > objects were created. > The fact that the offset is the one active at object creation is the key > error, because it should be the offset active when the date occurred. ----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Cheers,
Sean |
|
|
Hi Sean, I'm sure I'm stepping on a mine field here but I'll give it a go. A date without a time should not have a meaningful timezone offset. If for some reason the implementation requires an offset it should have some meaningless offset added. It does give you the local timezone which may be of some value to dates although why is a mystery to me. Unless you have a time to go with it it seems meaningless. Anyway assuming there is a value to an offset on a date Note that TimeSpan >> asDate ^start asDate. This makes sense to me because it just sets the time offset to midnight. start on TimeSpan and Date is a DateAndTime DateAndTime >> asDate ^ Date starting: self Date class >> starting: aDateAndTime ^super starting: (aDateAndTime midnight) duration: (Duration days: 1) Date on the other hand just returns self. if Date >> asDate ^start asDate, like TimeSpan does then you could recreate the dates as you go and come closer to fixing your problem by doing aDate asDate = '1/1/1901' asDate. Now the error window is much much smaller because it still matters when asDate is performed. Another fix is to just compare what you are actually concerned about. aDate yyyymmdd = '1/1/1901' asDate yyyymmdd Still I'm not sure there is a value in having the offset and maybe dates should just be dates. :) All the best, Ron Teitelbaum On Wed, Sep 4, 2019 at 12:52 PM Sean P. DeNigris <[hidden email]> wrote: Did the recent changes to Squeak's Date/Time handling (or any 3rd party lib) |
|
|
In reply to this post by Sean P. DeNigris
On Wed, Sep 04, 2019 at 11:52:47AM -0500, Sean P. DeNigris wrote:
> Did the recent changes to Squeak's Date/Time handling (or any 3rd party lib) > ever solve the following longstanding Chronology bug: > > >Consider this thought experiment: > > At 11:59pm before DST changes, eval aDate := '1/1/1901' asDate. > > Now, wait two minutes and at 12:01am eval self assert: '1/1/1901' asDate = > > aDate and??? whammo, an exception! > > The "different" offsets render equal dates unequal depending on when the > > objects were created. > > The fact that the offset is the one active at object creation is the key > > error, because it should be the offset active when the date occurred. I would expect that this is no longer a problem. Equality of DateAndTime is now based on comparing magnitude, expressed as microseconds since Posix epoch, and independent of time zone offset. '1/1/1901' asDate => 1 January 1901 '1/1/1901' asDate start ==> 1901-01-01T00:00:00+00:00 '1/1/1901' asDate start utcMicroseconds ==> -2177452800000000 '1/1/1901' asDate start offsetSeconds ==> 0 '1/1/1901' asDate start offset ==> 0:00:00:00 '1/1/1901' asDate duration ==> 1:00:00:00 In other words, if two Date instances start at the same utcMicroseconds, they will compare equal, regardless of when and where they were created. All of this should be completely independent of the current timezone offset for the machine on which it is evaluated. This does *not* handle the case of a Date for which duration is not 1:00:00:00, as would be the case for a "date" during which a daylight savings transition occured. This is a conceptual problem resulting from the definition of a "date" as a duration with a start time and a duration of 24 hours. The recent changes to Squeak's Date/Time handling do not attempt to address that problem. Dave |
|
|
In reply to this post by Sean P. DeNigris
Hi Sean, No. The recent UTCDateAndTime format change to Squeak made no difference in this regard. The example you gave had already been fixed previously by the introduction of #defaultOffset back in 2012. Dates created in non-TZ-specific contexts all get a defaultOffset of 0:00. So, in your example, '1/1/1901' asDate has no time-specific information, so it would inherit the defaultOffset (0:00), which compares favorably to other Dates with the same offset. Only Dates which were created via: myDateAndTime asDate would inherit the timezone from myDateAndTime, and therefore represent a different period of time than the ones that began at offset 0:00. - Chris On Wed, Sep 4, 2019 at 11:52 AM Sean P. DeNigris <[hidden email]> wrote: Did the recent changes to Squeak's Date/Time handling (or any 3rd party lib) >Consider this thought experiment: |
|
|
Hi Chris, Just wondering what the benefit of myDateAndTime asDate holding the timezone information is used for. Do you report dates based on Timezone from the saved date? That is the only real benefit I can think of because without the actual time you don't know if the date is wrong for any particular context. I'm just interested to know how the offset might be used. Thanks! All the best, Ron Teitelbaum On Thu, Sep 5, 2019 at 4:56 PM Chris Muller <[hidden email]> wrote:
|
|
|
I believe Brent developed Chronology from a simple and steadfast conceptual model of time: - A point in time (DateAndTime+TZ) - A duration of time (Duration) - A span of time beginning from a specific point (Timespan) Steadfastly to the model, Minute, Hour and Date implementations emerged as "spans" of time of those given Durations, and beginning from whatever the client-specified point in time was, including TZ. From there, Chronology left it up to clients to do what was necessary to fit their use cases. The problem is that "Canonical Date" is a use-case is immensely common that, yes, it felt like a "longstanding bug" for Chronology not to address it. We finally did in a way that preserves those original tenets of the domain. Best, Chris On Thu, Sep 5, 2019 at 6:08 PM Ron Teitelbaum <[hidden email]> wrote:
|
|
|
Hi Chris, That makes sense to me. Still shouldn't myDateAndTime asDate also have no time-specific information or is there a benefit to it? The bug persists if you accidentally create a date from one or the other and compare them. I'm still struggling to find any reason to have the offset set to a date of any kind that doesn't have a time attached to it. It might make sense if we knew or could sort out dates that didn't belong but with without the time you don't even know that. That only reason I can think of would be to separate dates created in different time zones for reporting but I keep thinking that even that seems wrong because I wouldn't want to depend on some obscure feature like that, instead I would make it more explicit and save the location directly. I think myDateAndTime asDate should also use the default offset of 0. All the best, Ron On Thu, Sep 5, 2019 at 7:47 PM Chris Muller <[hidden email]> wrote:
|
|
|
Hi Ron,
"Benefit" is from the eye of each user, of course. Date was modeled like Hour and Minute, as a Timespan. For applications modeling, say, a proper chronological sequence of events, yes, it would be essential for like Dates to still represent the distinct spans just as they did in real life. My September 6th began at my midnight, not the same time as someone elses across the globe. Chronology provides the resolution to support this. Truncating that resolution is up to applications. When using Chronology, developers need to remember it maintains a robust model of time which serves domains other than the one they're working on. Truncating precision (e.g., a DateAndTime asDate) in applications is pretty rare, but certainly not something to do willy-nilly. Developer's with any chance of success must give long enough pause to wonder and research about the nature of any and all coercions they perform in their applications.
No. That would make it inconsistent with #asHour and #asMinute. Best, Chris
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |