Re: [Pharo-project] Epoch returns local offset

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

Re: [Pharo-project] Epoch returns local offset

Eliot Miranda-2


On Fri, May 18, 2012 at 4:47 PM, David T. Lewis <[hidden email]> wrote:
On Fri, May 18, 2012 at 09:30:32PM +0200, Bert Freudenberg wrote:
> On 18.05.2012, at 19:22, Eliot Miranda wrote:
>
> > 'From Smalltalk-80, version 2, of April 1, 1983 on 31 May 1983 at 9:10:35 am'!
>
> That's obviously an April Fool's joke ;)
>
>
> But very interesting indeed. I had assumed that the way Squeak handles
> time is identical to how Smalltalk-80 did it. Apparently not, they must
> have simplified in the Mac version.
>
> - Bert -
>

The original Squeak implementation of Time class>>totalSeconds uses
primSecondsClock, which is documented as:

primSecondsClock
       "Answer the number of seconds since 00:00 on the morning of
        January 1, 1901 (a 32-bit unsigned number).
        Essential. See Object documentation whatIsAPrimitive. "

This does not specify whether it refers to the local time zone or to GMT,
and the actual implementation in Squeak has always used local time.

The Blue Book documents Time class>totalSeconds as "Answer the total seconds
from Jan. 1, 1901, corrected for time zone and daylight savings time."

And Time class>>timeWords is "Answer the seconds (in Greenwich Mean Time)
since Jan. 1, 1901 ..."

So it certainly does sound like totalSeconds was intended to be seconds
since Jan. 1, 1901 GMT, and it also appears that totalSeconds has been
implemented differently in Squeak.

After seeing Eliot's code reference, I'm inclined to think that the Blue
Book provided an unambiguous definition (though poorly worded), and that
Squeak has apparently been implementing it differently all along. There
is nothing in the Squeak image itself that gives a clue as to the original
intent (Time class>>timeWords is not present in Squeak), so the conflicting
implementations are now in wide circulation.

None of this does much to convince me that refering to a clearly defined
Posix epoch would be a bad idea ...

Bit it's so dull ;)  The start of the 20th century, albeit the traditional 01 start instead of the colloquial 00 start, is so much nicer.  I strongly suspect that 1970 was chosen more because of the absence of large integer arithmetic in libc (31 bit seconds run aground in 2038), and so is mere pragmatism.  Some of us were already born in 1970, and I hate being negative.


Dave





--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Epoch returns local offset

Igor Stasenko
On 19 May 2012 01:55, Eliot Miranda <[hidden email]> wrote:

>
>
> On Fri, May 18, 2012 at 4:47 PM, David T. Lewis <[hidden email]> wrote:
>>
>> On Fri, May 18, 2012 at 09:30:32PM +0200, Bert Freudenberg wrote:
>> > On 18.05.2012, at 19:22, Eliot Miranda wrote:
>> >
>> > > 'From Smalltalk-80, version 2, of April 1, 1983 on 31 May 1983 at
>> > > 9:10:35 am'!
>> >
>> > That's obviously an April Fool's joke ;)
>> >
>> >
>> > But very interesting indeed. I had assumed that the way Squeak handles
>> > time is identical to how Smalltalk-80 did it. Apparently not, they must
>> > have simplified in the Mac version.
>> >
>> > - Bert -
>> >
>>
>> The original Squeak implementation of Time class>>totalSeconds uses
>> primSecondsClock, which is documented as:
>>
>> primSecondsClock
>>        "Answer the number of seconds since 00:00 on the morning of
>>         January 1, 1901 (a 32-bit unsigned number).
>>         Essential. See Object documentation whatIsAPrimitive. "
>>
>> This does not specify whether it refers to the local time zone or to GMT,
>> and the actual implementation in Squeak has always used local time.
>>
>> The Blue Book documents Time class>totalSeconds as "Answer the total
>> seconds
>> from Jan. 1, 1901, corrected for time zone and daylight savings time."
>>
>> And Time class>>timeWords is "Answer the seconds (in Greenwich Mean Time)
>> since Jan. 1, 1901 ..."
>>
>> So it certainly does sound like totalSeconds was intended to be seconds
>> since Jan. 1, 1901 GMT, and it also appears that totalSeconds has been
>> implemented differently in Squeak.
>>
>> After seeing Eliot's code reference, I'm inclined to think that the Blue
>> Book provided an unambiguous definition (though poorly worded), and that
>> Squeak has apparently been implementing it differently all along. There
>> is nothing in the Squeak image itself that gives a clue as to the original
>> intent (Time class>>timeWords is not present in Squeak), so the
>> conflicting
>> implementations are now in wide circulation.
>>
>> None of this does much to convince me that refering to a clearly defined
>> Posix epoch would be a bad idea ...
>
>
> Bit it's so dull ;)  The start of the 20th century, albeit the traditional
> 01 start instead of the colloquial 00 start, is so much nicer.  I strongly
> suspect that 1970 was chosen more because of the absence of large integer
> arithmetic in libc (31 bit seconds run aground in 2038), and so is mere
> pragmatism.  Some of us were already born in 1970, and I hate being
> negative.
>
i'm in a mood of extending your metaphor :)
Now i can clearly tell, what caused the extinction of dinosaurs! :)

>>
>> Dave
>>
>>
>
>
>
> --
> best,
> Eliot
>
>
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Epoch returns local offset

David T. Lewis
In reply to this post by Eliot Miranda-2
On Fri, May 18, 2012 at 04:55:39PM -0700, Eliot Miranda wrote:

> On Fri, May 18, 2012 at 4:47 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Fri, May 18, 2012 at 09:30:32PM +0200, Bert Freudenberg wrote:
> > > On 18.05.2012, at 19:22, Eliot Miranda wrote:
> > >
> > > > 'From Smalltalk-80, version 2, of April 1, 1983 on 31 May 1983 at
> > 9:10:35 am'!
> > >
> > > That's obviously an April Fool's joke ;)
> > >
> > >
> > > But very interesting indeed. I had assumed that the way Squeak handles
> > > time is identical to how Smalltalk-80 did it. Apparently not, they must
> > > have simplified in the Mac version.
> > >
> > > - Bert -
> > >
> >
> > The original Squeak implementation of Time class>>totalSeconds uses
> > primSecondsClock, which is documented as:
> >
> > primSecondsClock
> >        "Answer the number of seconds since 00:00 on the morning of
> >         January 1, 1901 (a 32-bit unsigned number).
> >         Essential. See Object documentation whatIsAPrimitive. "
> >
> > This does not specify whether it refers to the local time zone or to GMT,
> > and the actual implementation in Squeak has always used local time.
> >
> > The Blue Book documents Time class>totalSeconds as "Answer the total
> > seconds
> > from Jan. 1, 1901, corrected for time zone and daylight savings time."
> >
> > And Time class>>timeWords is "Answer the seconds (in Greenwich Mean Time)
> > since Jan. 1, 1901 ..."
> >
> > So it certainly does sound like totalSeconds was intended to be seconds
> > since Jan. 1, 1901 GMT, and it also appears that totalSeconds has been
> > implemented differently in Squeak.
> >
> > After seeing Eliot's code reference, I'm inclined to think that the Blue
> > Book provided an unambiguous definition (though poorly worded), and that
> > Squeak has apparently been implementing it differently all along. There
> > is nothing in the Squeak image itself that gives a clue as to the original
> > intent (Time class>>timeWords is not present in Squeak), so the conflicting
> > implementations are now in wide circulation.
> >
> > None of this does much to convince me that refering to a clearly defined
> > Posix epoch would be a bad idea ...
> >
>
> Bit it's so dull ;)  The start of the 20th century, albeit the traditional
> 01 start instead of the colloquial 00 start, is so much nicer.  I strongly
> suspect that 1970 was chosen more because of the absence of large integer
> arithmetic in libc (31 bit seconds run aground in 2038), and so is mere
> pragmatism.

There probably was no such thing as libc back then, but it was pragmatism
for sure. Assuming that the first unix system was done in the 1969-1971
time frame, and knowing that time() was one of the small set of system
calls (aka primitives) on those early systems running on limited hardware
resources (http://en.wikipedia.org/wiki/PDP-7), the choice of 1970 as
the origin for the system clock would have been a no-brainer.

It's interesting to contrast this with Smalltalk, which was invented
in the same time frame, and would have been subject to similar hardware
constraints. For Smalltalk, there was evidently been no motivation
to pack the visible time horizon into a 32-bit value, perhaps in part
because a SmallInteger is not that wide (and thus would have run aground
well before 2038), but more importantly because it is natural in Smalltalk
to handle this sort of logic in the image.

> Some of us were already born in 1970, and I hate being negative.
>

That's an excellent point, I never thought of it in those terms. Being
well into negative terratory myself in that regard, I'm beginning to
warm up to your point of view ;)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Epoch returns local offset

espin
In reply to this post by David T. Lewis
The choise of epoch is arbitrary, Calendrical Calculations,
set it to Rata Die 0 and defines all the ones for the other calendars
- Mayan, Gregorian, Julian, Persian ... - accordingly.

I did implement the Python equivalent of the Common Lisp code
from the book, you can browse both in my pycalcal project page
(Python code is in the zip distribution).

I have a yet unfinished implementation in Smalltalk on squeaksource
called Calendrica.

Bye
Enrico

On Thu, May 17, 2012 at 2:26 AM, David T. Lewis <[hidden email]> wrote:
(cross posting to squeak-dev)

On Wed, May 16, 2012 at 01:50:16PM -0700, Sean P. DeNigris wrote:
>
> David T. Lewis wrote
> >
> > So no, it is not a constant.
> >
>
> Let me rephrase: wouldn't it be better if it was a constant, like dos and
> unix?

Yes it would be better if the Smalltalk epoch was an unambiguously defined
value, but unfortunately it is not. That is the reason that the clearly
defined Posix epoch would be a more suitable basis for these calculations.

<ot>
Funny that you should mention DOS. DOS has exactly the same problem
as Squeak/Pharo in this regard. It was originally designed as a simple
single-user system, where the user was expected to set the clock properly
on all of his/her alarm clocks, kitchen appliances, and computers. It
has no knowledge of time zones or daylight savings time, and this leads
to all sorts of bugs in applications running on MS-DOS that assume that
the system time is correct. I was dealing with a real-life bug of this
sort last week that had people spending huge amounts of time and energy
trying to figure out what was causing clocks to be "reset" in a complex
multi-platform application that happened to include some old DOS based
computers that were sending time stamped messages.
</ot>

> I find the current behavior confusing e.g.
>
> dt := '1/15/2012 0000+00:00' asDateAndTime.
>
> DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation
> = 'PDT' ]).
> s := dt asSeconds. "3504013200"
>
> "Now I move to Greenwich"
> DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation
> = 'UTC' ]).
> DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!"
>

Yes, that looks broken to me too. But DateAndTime class>>fromSeconds: is
documented as "Answer a DateAndTime since the Squeak epoch: 1 January 1901"
which by definition cannot be correctly implemented.

One solution would be to gain agreement among all flavors of Smalltalk
as to the proper definition of the Smalltalk epoch. But it seems to me
that it would be vastly simpler to just use a definition that is already
agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch"
behind as an interesting historical artifact.

Dave





--
Enrico Spinielli
"Do Androids dream of electric sheep?"— Philip K. Dick
"Hear and forget; see and remember;do and understand."—Mitchel Resnick
"He who refuses to do arithmetic is doomed to talk nonsense."—John McCarthy


12