DateAndTimeLeapTest>>testAsSeconds is broken

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DateAndTimeLeapTest>>testAsSeconds is broken

David T. Lewis
DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a
result of a false assertion:

        self assert: aDateAndTime asSeconds = 3255514380.

Where aDateAndTime is specified in #setUp

        aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours).

This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.

The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch
until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration
is 3255507180, not 3255514380 as asserted in the unit test.

By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch
(see its method comment). By common agreement, the Smalltalk epoch was defined
relative to Greenwich Mean Time (UTC). If these two statements are both true,
then the test is broken.

If there is no disagreement, I will fix the test and allow it to show the failure.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Bert Freudenberg
On Thu, Dec 1, 2016 at 4:51 AM, David T. Lewis <[hidden email]> wrote:
DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a
result of a false assertion:

        self assert: aDateAndTime asSeconds = <a href="tel:3255514380" value="+13255514380">3255514380.

Where aDateAndTime is specified in #setUp

        aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours).

This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.

The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch
until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration
is 3255507180, not 3255514380 as asserted in the unit test.

By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch
(see its method comment). By common agreement, the Smalltalk epoch was defined
relative to Greenwich Mean Time (UTC). If these two statements are both true,
then the test is broken.

If there is no disagreement, I will fix the test and allow it to show the failure.

Not necessarily disagreeing, but previously Squeak epoch was defined as local time. This is why "DateAndTime epoch" answers a local time.

This is basically because we had no time zone support at all, and no way to convert to UTC.

I agree basing it on UTC makes more sense, but I'm not sure how much code would need to change, and if some stored datetimes would be affected.

- Bert - 



Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

David T. Lewis
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:

> On Thu, Dec 1, 2016 at 4:51 AM, David T. Lewis <[hidden email]> wrote:
>
> > DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly
> > as a
> > result of a false assertion:
> >
> >         self assert: aDateAndTime asSeconds = 3255514380.
> >
> > Where aDateAndTime is specified in #setUp
> >
> >         aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13
> > minute: 33 second: 0 offset: 2 hours).
> >
> > This time is 2004-02-29T13:33:00+02:00, which in UTC is
> > 2004-02-29T11:33:00+00:00.
> >
> > The #asSeconds tests should test for elapsed seconds from the Smalltalk
> > epoch
> > until 2004-02-29T11:33:00+00:00. The correct number of seconds for this
> > duration
> > is 3255507180, not 3255514380 as asserted in the unit test.
> >
> > By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch
> > (see its method comment). By common agreement, the Smalltalk epoch was
> > defined
> > relative to Greenwich Mean Time (UTC). If these two statements are both
> > true,
> > then the test is broken.
> >
> > If there is no disagreement, I will fix the test and allow it to show the
> > failure.
> >
>
> Not necessarily disagreeing, but previously Squeak epoch was defined as
> local time. This is why "DateAndTime epoch" answers a local time.
>
> This is basically because we had no time zone support at all, and no way to
> convert to UTC.
>
> I agree basing it on UTC makes more sense, but I'm not sure how much code
> would need to change, and if some stored datetimes would be affected.
>

Here I am raising a different (but admittedly related) question. How many seconds
elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?

Dave


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Bert Freudenberg
On Thu, Dec 1, 2016 at 2:29 PM, David T. Lewis <[hidden email]> wrote:
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote: 
Here I am raising a different (but admittedly related) question. How many seconds
elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?

=> 3255507180 + DateAndTime localOffset asSeconds 

My reasoning:  

('1901-01-01T00:00:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds  = (0 + DateAndTime localOffset asSeconds - 7200)

and so

('2004-02-29T13:33:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = (3255514380 + DateAndTime localOffset asSeconds - 7200)

It can't be a constant but needs to take into account the local time zone. Because Smalltalk epoch is defined as local time, the difference to a fixed time necessarily involves the timezone offset.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Bert Freudenberg
On Thu, Dec 1, 2016 at 4:17 PM, Bert Freudenberg <[hidden email]> wrote:
On Thu, Dec 1, 2016 at 2:29 PM, David T. Lewis <[hidden email]> wrote:
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote: 
Here I am raising a different (but admittedly related) question. How many seconds
elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?

=> <a href="tel:(325)%20550-7180" value="+13255507180" target="_blank">3255507180 + DateAndTime localOffset asSeconds 

My reasoning:  

('1901-01-01T00:00:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds  = (0 + DateAndTime localOffset asSeconds - 7200)

and so

('2004-02-29T13:33:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = <a href="tel:(325)%20551-4380" value="+13255514380" target="_blank">(3255514380 + DateAndTime localOffset asSeconds - 7200)

It can't be a constant but needs to take into account the local time zone. Because Smalltalk epoch is defined as local time, the difference to a fixed time necessarily involves the timezone offset.

Ah, but #asSeconds uses the epoch in the time zone of that DateAndTime instance, so it *is* a constant after all ... But it's not constant wrt your own local time zone.

Then again, maybe fromSeconds: and asSeconds should be symmetric. They're not, because asSeconds uses the instance's time zone, but fromSeconds: uses local time zone.

It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

David T. Lewis
On Thu, Dec 01, 2016 at 04:53:24PM +0100, Bert Freudenberg wrote:

> On Thu, Dec 1, 2016 at 4:17 PM, Bert Freudenberg <[hidden email]>
> wrote:
>
> > On Thu, Dec 1, 2016 at 2:29 PM, David T. Lewis <[hidden email]>
> > wrote:
> >
> >> On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:
> >>
> > Here I am raising a different (but admittedly related) question. How many
> >> seconds
> >> elapsed between the Smalltalk epoch and the time
> >> 2004-02-29T13:33:00+02:00?
> >>
> >
> > => 3255507180 <(325)%20550-7180> + DateAndTime localOffset asSeconds
> >
> > My reasoning:
> >
> > ('1901-01-01T00:00:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds
> >  = (0 + DateAndTime localOffset asSeconds - 7200)
> >
> > and so
> >
> > ('2004-02-29T13:33:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds
> > = (3255514380 <(325)%20551-4380> + DateAndTime localOffset asSeconds -
> > 7200)
> >
> > It can't be a constant but needs to take into account the local time zone.
> > Because Smalltalk epoch is defined as local time, the difference to a fixed
> > time necessarily involves the timezone offset.
> >
>
> Ah, but #asSeconds uses the epoch in the time zone of that DateAndTime
> instance, so it *is* a constant after all ... But it's not constant wrt
> your own local time zone.

Right. Neither of which makes any logical sense, because even if you wanted
to define "epoch" relative to your local time zone, its value would change
the next time you encounter a daylight savings time transition. And if you
think that your "epoch" is relative to the offset of a DateAndTime instance
that may or may not have been created in your local time zone, then that is
another "epoch" entirely.

Furthermore, an instance of DateAndTime does not have a time zone, it has
an offset, which is not the same thing at all. The offset for any given
DateAndTime may or may not correspond to the time zone in which your Squeak
image happens to be running. And the offset for any given time zone will vary
as a function of time due to daylight savings time rules and other political
factors (in the real world, not in Squeak).

>
> Then again, maybe fromSeconds: and asSeconds should be symmetric. They're
> not, because asSeconds uses the instance's time zone, but fromSeconds: uses
> local time zone.

Right. At the very least it should be symmetric.

>
> It's also quit possible I'm totally confused - I did not use independent
> resources but was just relying on Squeak.
>

Well yes, of course you are confused, you should be. I would have been very
worried if you looked at this and thought that it made any sense ;-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

David T. Lewis
In reply to this post by Bert Freudenberg
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:
>
> I agree basing it on UTC makes more sense, but I'm not sure how much code
> would need to change, and if some stored datetimes would be affected.
>

Indeed, changing the instance variable format for DateAndTime does require the
ability to deserialize old instances that may have been stored in the snapshot.bin
of an MCZ file.

I just added this to the UTCDateAndTime project on squeaksource.com:

   Name: Chronology-Core-dtl.24
   Author: dtl
   Time: 1 December 2016, 10:20:50.201532 pm
   UUID: 961522d3-4d2a-42e8-bafc-f4ee338542bf
   Ancestors: Chronology-Core-dtl.23
   
   Handle DataStream deserialization of old format DateAndTime by converting to
   the new format. This is required for reading instances that have been saved
   in the snapshot.bin of a Monticello MCZ archive. If deserializing the snapshot.bin
   works at all, then it must also handle the special case of DataAndTime instances
   that were serialized with the old DateAndTime instance format.

I think this handles the DataStream cases properly. Similar patches might be required
for MASerializer and Fuel.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller-3
In reply to this post by David T. Lewis
>> It's also quit possible I'm totally confused - I did not use independent
>> resources but was just relying on Squeak.
>>
>
> Well yes, of course you are confused, you should be. I would have been very
> worried if you looked at this and thought that it made any sense ;-)

I haven't quite groked the issue myself just yet, but you definitely
sound convinced there's a tangible issue, Dave.  I agree that symmetry
between those two converting methods sounds like it should be..

You said the number of seconds calculated since the "epoch" is wrong
but mentioned it was merely in conflict with a comment.  If we "fixed"
the comment, would we still have a problem?

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Levente Uzonyi
On Fri, 2 Dec 2016, Chris Muller wrote:

>>> It's also quit possible I'm totally confused - I did not use independent
>>> resources but was just relying on Squeak.
>>>
>>
>> Well yes, of course you are confused, you should be. I would have been very
>> worried if you looked at this and thought that it made any sense ;-)
>
> I haven't quite groked the issue myself just yet, but you definitely
> sound convinced there's a tangible issue, Dave.  I agree that symmetry
> between those two converting methods sounds like it should be..
>
> You said the number of seconds calculated since the "epoch" is wrong
> but mentioned it was merely in conflict with a comment.  If we "fixed"
> the comment, would we still have a problem?

Do you know the answer to Dave's question "How many seconds elapsed
between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?

Levente

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller-4
Why does it matter exactly how many seconds since the epoch?

On Fri, Dec 2, 2016 at 3:48 PM, Levente Uzonyi <[hidden email]> wrote:

> On Fri, 2 Dec 2016, Chris Muller wrote:
>
>>>> It's also quit possible I'm totally confused - I did not use independent
>>>> resources but was just relying on Squeak.
>>>>
>>>
>>> Well yes, of course you are confused, you should be. I would have been
>>> very
>>> worried if you looked at this and thought that it made any sense ;-)
>>
>>
>> I haven't quite groked the issue myself just yet, but you definitely
>> sound convinced there's a tangible issue, Dave.  I agree that symmetry
>> between those two converting methods sounds like it should be..
>>
>> You said the number of seconds calculated since the "epoch" is wrong
>> but mentioned it was merely in conflict with a comment.  If we "fixed"
>> the comment, would we still have a problem?
>
>
> Do you know the answer to Dave's question "How many seconds elapsed between
> the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
>
> Levente

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Levente Uzonyi
If it doesn't matter, then what's the epoch good for?

Levente

On Sat, 3 Dec 2016, Chris Muller wrote:

> Why does it matter exactly how many seconds since the epoch?
>
> On Fri, Dec 2, 2016 at 3:48 PM, Levente Uzonyi <[hidden email]> wrote:
>> On Fri, 2 Dec 2016, Chris Muller wrote:
>>
>>>>> It's also quit possible I'm totally confused - I did not use independent
>>>>> resources but was just relying on Squeak.
>>>>>
>>>>
>>>> Well yes, of course you are confused, you should be. I would have been
>>>> very
>>>> worried if you looked at this and thought that it made any sense ;-)
>>>
>>>
>>> I haven't quite groked the issue myself just yet, but you definitely
>>> sound convinced there's a tangible issue, Dave.  I agree that symmetry
>>> between those two converting methods sounds like it should be..
>>>
>>> You said the number of seconds calculated since the "epoch" is wrong
>>> but mentioned it was merely in conflict with a comment.  If we "fixed"
>>> the comment, would we still have a problem?
>>
>>
>> Do you know the answer to Dave's question "How many seconds elapsed between
>> the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
>>
>> Levente
>

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller-4
In reply to this post by Levente Uzonyi
> Do you know the answer to Dave's question "How many seconds elapsed between
> the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?

IOW, as long as this private, internal number is consistent for the
callers, does it matter what the number is?  Whether the internal
"starting point" is midnight, 2am, 6am or 7:37:59am for that matter?
The comment just says "1 January 1901" it does not specify a time,
could we just clarify the exact time in the comment and then
everything be fine?

Or is there some calculation or scenario for an application that is
not consistent and correct due to this?

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller-4
One issue appears to be that the #epoch is calculated relative to
"self localOffset".  So #epoch reports technically different times
depending what one's #localOffset is.

|dt1 dt2| dt1:= '2004-02-29T13:33:00+02:00' asDateAndTime.
dt2 := '2004-02-29T11:33:00+00:00' asDateAndTime.
self assert: dt1 = dt2.
self assert: dt1 asSeconds = dt2 asSeconds.   "fails!"

This is bad, isn't it?



On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller <[hidden email]> wrote:

>> Do you know the answer to Dave's question "How many seconds elapsed between
>> the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
>
> IOW, as long as this private, internal number is consistent for the
> callers, does it matter what the number is?  Whether the internal
> "starting point" is midnight, 2am, 6am or 7:37:59am for that matter?
> The comment just says "1 January 1901" it does not specify a time,
> could we just clarify the exact time in the comment and then
> everything be fine?
>
> Or is there some calculation or scenario for an application that is
> not consistent and correct due to this?

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Levente Uzonyi
On Sat, 3 Dec 2016, Chris Muller wrote:

> One issue appears to be that the #epoch is calculated relative to
> "self localOffset".  So #epoch reports technically different times
> depending what one's #localOffset is.
>
> |dt1 dt2| dt1:= '2004-02-29T13:33:00+02:00' asDateAndTime.
> dt2 := '2004-02-29T11:33:00+00:00' asDateAndTime.
> self assert: dt1 = dt2.
> self assert: dt1 asSeconds = dt2 asSeconds.   "fails!"
>
> This is bad, isn't it?

That's exactly the problem. It gets worse when your localOffset changes,
or you want to use instances created in different localOffsets.

Levente

>
>
>
> On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller <[hidden email]> wrote:
>>> Do you know the answer to Dave's question "How many seconds elapsed between
>>> the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
>>
>> IOW, as long as this private, internal number is consistent for the
>> callers, does it matter what the number is?  Whether the internal
>> "starting point" is midnight, 2am, 6am or 7:37:59am for that matter?
>> The comment just says "1 January 1901" it does not specify a time,
>> could we just clarify the exact time in the comment and then
>> everything be fine?
>>
>> Or is there some calculation or scenario for an application that is
>> not consistent and correct due to this?
>

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller-3
It sounds like we all agree that #epoch would be better as a true
constant, not specific to one's timezone.  If so, we should probably
change it to....

epoch
     "Answer a DateAndTime representing the Squeak epoch:
(1901-01-01T00:00:00+00:00)"
     ^ self
          julianDayNumber: SqueakEpoch
          offset: Duration zero

If we also revert DateAndTime>>#asSeconds back to Brent's original from 2003:

asSeconds
     "Return the number of seconds since the Squeak epoch"
     ^ (self - (self class epoch)) asSeconds

then that would fix the symmetry issue and bring us full-circle back
to what Dave was saying about DateAndTimeLeapTest in the first place.

Hmm..  Magma used DateAndTime>>#asSeconds to store the integral
representation of the timestamp of its commit-log records..  however,
as the commit-log records are rarely consumed at all, I think this
should be okay.

Does anyone else have any major impacts?  Dave, you mentioned objects
in the snapshot.bin files, needing a "format" conversion, what is
that?

On Sat, Dec 3, 2016 at 3:19 PM, Levente Uzonyi <[hidden email]> wrote:

> On Sat, 3 Dec 2016, Chris Muller wrote:
>
>> One issue appears to be that the #epoch is calculated relative to
>> "self localOffset".  So #epoch reports technically different times
>> depending what one's #localOffset is.
>>
>> |dt1 dt2| dt1:= '2004-02-29T13:33:00+02:00' asDateAndTime.
>> dt2 := '2004-02-29T11:33:00+00:00' asDateAndTime.
>> self assert: dt1 = dt2.
>> self assert: dt1 asSeconds = dt2 asSeconds.   "fails!"
>>
>> This is bad, isn't it?
>
>
> That's exactly the problem. It gets worse when your localOffset changes, or
> you want to use instances created in different localOffsets.
>
> Levente
>
>
>>
>>
>>
>> On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller <[hidden email]>
>> wrote:
>>>>
>>>> Do you know the answer to Dave's question "How many seconds elapsed
>>>> between
>>>> the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
>>>
>>>
>>> IOW, as long as this private, internal number is consistent for the
>>> callers, does it matter what the number is?  Whether the internal
>>> "starting point" is midnight, 2am, 6am or 7:37:59am for that matter?
>>> The comment just says "1 January 1901" it does not specify a time,
>>> could we just clarify the exact time in the comment and then
>>> everything be fine?
>>>
>>> Or is there some calculation or scenario for an application that is
>>> not consistent and correct due to this?
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

David T. Lewis
On Sat, Dec 03, 2016 at 04:06:10PM -0600, Chris Muller wrote:
>
> Hmm..  Magma used DateAndTime>>#asSeconds to store the integral
> representation of the timestamp of its commit-log records..  however,
> as the commit-log records are rarely consumed at all, I think this
> should be okay.

Think about what would happen if someone was actively using a Magma
database during a "fall back" daylight savings time transition period.

>
> Does anyone else have any major impacts?  Dave, you mentioned objects
> in the snapshot.bin files, needing a "format" conversion, what is
> that?

That is a separate topic. In UTCDateAndTime I changed the instance variables
in DateAndTime, which requires considering what to do with "old format"
instances that may be stored in a snapshot.bin and need to be materialized
while processing the Monticello update stream that I prepared for UTCDateAndTime.
I added the necessary support recently, but I will need to rebuild the update
stream is there is interest in using it.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

David T. Lewis
In reply to this post by David T. Lewis
On Wed, Nov 30, 2016 at 10:51:05PM -0500, David T. Lewis wrote:

> DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a
> result of a false assertion:
>
> self assert: aDateAndTime asSeconds = 3255514380.
>
> Where aDateAndTime is specified in #setUp
>
> aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours).
>
> This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.
>
> The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch
> until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration
> is 3255507180, not 3255514380 as asserted in the unit test.
>
> By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch
> (see its method comment). By common agreement, the Smalltalk epoch was defined
> relative to Greenwich Mean Time (UTC). If these two statements are both true,
> then the test is broken.
>
> If there is no disagreement, I will fix the test and allow it to show the failure.

This thread has generated some interesting discussion, but my original
question remains.

The correct number of elapsed seconds from the Smalltalk epoch to
2004-02-29T13:33:00+02:00 is 3255507180. I want to change #testAsSeconds
assert this value. The test will fail, as it should.

Any objections?

Dave

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller-3
In reply to this post by David T. Lewis
On Sat, Dec 3, 2016 at 5:12 PM, David T. Lewis <[hidden email]> wrote:
> On Sat, Dec 03, 2016 at 04:06:10PM -0600, Chris Muller wrote:
>>
>> Hmm..  Magma used DateAndTime>>#asSeconds to store the integral
>> representation of the timestamp of its commit-log records..  however,
>> as the commit-log records are rarely consumed at all, I think this
>> should be okay.
>
> Think about what would happen if someone was actively using a Magma
> database during a "fall back" daylight savings time transition period.

Unless I'm missing something, that example does not relate to this.
The timestamps in the logs would merely reflect the local time, which
would retrace itself by one hour.  A similar retracement would still
occur even after we fixed this, right?  The only impact I can think of
is if someone wanted to restore the database to a prior point in time
*within* that retraced period; in which their time specification would
be ambiguous as it naturally is in the real world anyway in a fallback
DST change..

>> Does anyone else have any major impacts?  Dave, you mentioned objects
>> in the snapshot.bin files, needing a "format" conversion, what is
>> that?
>
> That is a separate topic. In UTCDateAndTime I changed the instance variables
> in DateAndTime, which requires considering what to do with "old format"
> instances that may be stored in a snapshot.bin and need to be materialized
> while processing the Monticello update stream that I prepared for UTCDateAndTime.
> I added the necessary support recently, but I will need to rebuild the update
> stream is there is interest in using it.

I am still interested, I just have to take the time and care to convert.

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller-3
In reply to this post by David T. Lewis
On Sat, Dec 3, 2016 at 6:03 PM, David T. Lewis <[hidden email]> wrote:

> On Wed, Nov 30, 2016 at 10:51:05PM -0500, David T. Lewis wrote:
>> DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a
>> result of a false assertion:
>>
>>       self assert: aDateAndTime asSeconds = 3255514380.
>>
>> Where aDateAndTime is specified in #setUp
>>
>>       aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours).
>>
>> This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.
>>
>> The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch
>> until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration
>> is 3255507180, not 3255514380 as asserted in the unit test.
>>
>> By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch
>> (see its method comment). By common agreement, the Smalltalk epoch was defined
>> relative to Greenwich Mean Time (UTC). If these two statements are both true,
>> then the test is broken.
>>
>> If there is no disagreement, I will fix the test and allow it to show the failure.
>
> This thread has generated some interesting discussion, but my original
> question remains.
>
> The correct number of elapsed seconds from the Smalltalk epoch to
> 2004-02-29T13:33:00+02:00 is 3255507180. I want to change #testAsSeconds
> assert this value. The test will fail, as it should.
>
> Any objections?

How do you count non-responses?  ;)

No objection from me, but since we're talking about persistent data,
this deserves some good patient thought so we're sure we really want
to change the meaning of #epoch to be a globalized constant rather
than a timezone-specific one.  If we do, then that test should be
fixed along with the other two methods, too.

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTimeLeapTest>>testAsSeconds is broken

David T. Lewis
In reply to this post by Levente Uzonyi
On Fri, Dec 02, 2016 at 10:48:30PM +0100, Levente Uzonyi wrote:

> On Fri, 2 Dec 2016, Chris Muller wrote:
>
> >>>It's also quit possible I'm totally confused - I did not use independent
> >>>resources but was just relying on Squeak.
> >>>
> >>
> >>Well yes, of course you are confused, you should be. I would have been
> >>very
> >>worried if you looked at this and thought that it made any sense ;-)
> >
> >I haven't quite groked the issue myself just yet, but you definitely
> >sound convinced there's a tangible issue, Dave.  I agree that symmetry
> >between those two converting methods sounds like it should be..
> >
> >You said the number of seconds calculated since the "epoch" is wrong
> >but mentioned it was merely in conflict with a comment.  If we "fixed"
> >the comment, would we still have a problem?
>
> Do you know the answer to Dave's question "How many seconds elapsed
> between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
>
> Levente
>

In a workspace:

smalltalkEpochUntilPosixEpoch := 24 * 60 * 60 * ((52*365) + (17*366)).

posixEpochUntilJanuary2004 := 24 * 60 * 60 * ((26*365) + (8*366)).

monthOfJanuary2004 := 31 * 24 * 60 * 60.

first28DaysOfFebruary2004 := 28 * 24 * 60 * 60.

firstElevenHoursOfFebruary29 := 11 * 60 * 60.

thirtyThreeMinutesOfTheEleventhHour := 33 * 60.

totalElapsedSeconds := smalltalkEpochUntilPosixEpoch + posixEpochUntilJanuary2004 + monthOfJanuary2004 + first28DaysOfFebruary2004 + firstElevenHoursOfFebruary29 + thirtyThreeMinutesOfTheEleventhHour.

totalElapsedSeconds. "==> 3255507180"

"Below works only if UTCDateAndTime is installed, else figure it out by hand"
(DateAndTime fromSeconds: totalElapsedSeconds) localOffsetSeconds: 2 * 60 * 60 ; yourself. "==> 2004-02-29T13:33:00+02:00"

 

12