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 <lewis at mail.msen.com> 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