Smalltalk › Squeak › Squeak - Dev

Re: [Pharo-project] Epoch returns local offset

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

David T. Lewis

Re: [Pharo-project] Epoch returns local offset

(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

Eliot Miranda-2

Re: [Pharo-project] Epoch returns local offset

On Wed, May 16, 2012 at 5:26 PM, 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.

I don't understand. What is ambiguous about the start of the 20-th century in GMT?

<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

--
best,

Eliot

Bert Freudenberg

Re: [Pharo-project] Epoch returns local offset

On 17.05.2012, at 19:29, Eliot Miranda wrote:

What is ambiguous about the start of the 20-th century in GMT?

Nothing. But Smalltalk epoch was not defined in GMT. It's local time.

- Bert -

Eliot Miranda-2

Re: [Pharo-project] Epoch returns local offset

On Thu, May 17, 2012 at 10:42 AM, Bert Freudenberg <[hidden email]> wrote:

On 17.05.2012, at 19:29, Eliot Miranda wrote:

What is ambiguous about the start of the 20-th century in GMT?

Nothing. But Smalltalk epoch was not defined in GMT. It's local time.

I'm not sure I buy that. Looking at Smalltalk-80 v2 the California timezone was hardwired in. So I think the epoch was in GMT and e.g. Time currentSeconds: #seconds answered the number of seconds from the GMT epoch. certainly that's what the Cog VMs answer. But there's nothing to stop us firming up the definition. 1970 is a pretty arbitrary choice of epoch. The start of the 20th century has a certain elegance. Even Microsoft have a nice epoch (the start of the gregorian calendar IIRC). Why slavishly follow unix when we have something distinctive and hard-wired into the VMs? Why not just define the Smalltalk epoch properly?

- Bert -

--
best,

Eliot

David T. Lewis

Re: [Pharo-project] Epoch returns local offset

On Thu, May 17, 2012 at 04:01:11PM -0700, Eliot Miranda wrote:

> On Thu, May 17, 2012 at 10:42 AM, Bert Freudenberg <[hidden email]>wrote:
>
> > On 17.05.2012, at 19:29, Eliot Miranda wrote:
> >
> > What is ambiguous about the start of the 20-th century in GMT?
> >
> >
> > Nothing. But Smalltalk epoch was not defined in GMT. It's local time.
> >
>
> I'm not sure I buy that. Looking at Smalltalk-80 v2 the California
> timezone was hardwired in. So I think the epoch was in GMT and e.g. Time
> currentSeconds: #seconds answered the number of seconds from the GMT epoch.

If that were actually true, someone would have said so when they described
the meaning of the Smalltalk epoch. But they did not say so, and no such
definition exists anywhere except in the unsubstantiated opinions and
misconceptions of you, me, and everyone else on this list.

You have illustrated the problem perfectly: "I think the epoch was ..."
is your interpretation of what you think that someone might have intended,
which may or may not correspond with what was actually intended, if in fact
they intended anything at all, which most probably they did not. This is not
an issue that would have been on the forefront of anyone's consideration when
designing a personal computing system for the empowerment of individuals.

> certainly that's what the Cog VMs answer. But there's nothing to stop us
> firming up the definition. 1970 is a pretty arbitrary choice of epoch.
> The start of the 20th century has a certain elegance.

I would have prefered to propose the end of the Mayan calendar as the
more elegant reference point, but unfortunately the definition of this
point in time appears to suffer from some ambiguity also ;-)

> Even Microsoft have
> a nice epoch (the start of the gregorian calendar IIRC). Why slavishly
> follow unix when we have something distinctive and hard-wired into the VMs?
> Why not just define the Smalltalk epoch properly?

Because after more than 10 years of answering questions about this stuff
over and over, it would be really nice to be able to simply refer people
to the relevant Wikipedia page, where the concepts are properly documented
and clearly explained.

I do appreciate the distinctive nature of the Smalltalk epoch, and it can
be retained indefinitely for sentimental and historical reasons. But it
simply is not suitable for use as the basis for time measurement, however
much we might wish it were otherwise.

Dave

Sean P. DeNigris

Re: [Pharo-project] Epoch returns local offset

Administrator

David T. Lewis wrote

it would be really nice to be able to simply refer people
to the relevant Wikipedia page, where the concepts are properly documented
and clearly explained.

If you decide to go with the Unix epoch, I made the changes (which ended up being minimal) in Pharo and all the relevant tests pass. The packages are in the Pharo inbox - Kernel-SeanDeNigris.1087, KernelTests-SeanDeNigris.406, Network-Mail-SeanDeNigris.11 & RecentSubmissions-SeanDeNigris.158

Cheers,
Sean

Cheers,
Sean

David T. Lewis

Re: [Pharo-project] Epoch returns local offset

On Thu, May 17, 2012 at 06:36:23PM -0700, Sean P. DeNigris wrote:

>
> David T. Lewis wrote
> >
> > it would be really nice to be able to simply refer people
> > to the relevant Wikipedia page, where the concepts are properly documented
> > and clearly explained.
> >
>
> If you decide to go with the Unix epoch, I made the changes (which ended up
> being minimal) in Pharo and all the relevant tests pass. The packages are in
> the Pharo inbox - Kernel-SeanDeNigris.1087, KernelTests-SeanDeNigris.406,
> Network-Mail-SeanDeNigris.11 & RecentSubmissions-SeanDeNigris.158

Thanks!

Dave

David T. Lewis

Re: [Pharo-project] Epoch returns local offset

In reply to this post by David T. Lewis

On Thu, May 17, 2012 at 08:59:35PM -0400, David T. Lewis wrote:
> On Thu, May 17, 2012 at 04:01:11PM -0700, Eliot Miranda wrote:
>
> > Why not just define the Smalltalk epoch properly?
>
> Because after more than 10 years of answering questions about this stuff
> over and over, it would be really nice to be able to simply refer people
> to the relevant Wikipedia page, where the concepts are properly documented
> and clearly explained.

I realized that I am probably coming across as a bit snarky with a remark
like this, sorry.

For background, Lex Spoon (with some help from me) proposed a good solution
to handle local versus UTC time back in early 2000. Squeak was based on
local time (both in the VM and in the image), so the idea was to provide
a primitive with time and offset in an atomic call, such that UTC clock values
would be available while providing the traditional local clock for compatibility
in the existing image.

http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-February/020249.html

The primitiveUtcWithOffset primitive in the interpreter VM is based on Lex
Spoon's original proposal.
"Answer an array with UTC microseconds since the Posix epoch and
the current seconds offset from GMT in the local time zone.
This is a named (not numbered) primitive in the null module (ie the VM)"

I take an interest in the topic because of this posting from 1999, which I
personally consider to be the most important thing that I have contributed
to Squeak over the years:

http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-December/005327.html

Dave

Nicolas Cellier

Re: [Pharo-project] Epoch returns local offset

2012/5/18 David T. Lewis <[hidden email]>:

> On Thu, May 17, 2012 at 08:59:35PM -0400, David T. Lewis wrote:
>> On Thu, May 17, 2012 at 04:01:11PM -0700, Eliot Miranda wrote:
>>
>> > Why not just define the Smalltalk epoch properly?
>>
>> Because after more than 10 years of answering questions about this stuff
>> over and over, it would be really nice to be able to simply refer people
>> to the relevant Wikipedia page, where the concepts are properly documented
>> and clearly explained.
>
> I realized that I am probably coming across as a bit snarky with a remark
> like this, sorry.
>
> For background, Lex Spoon (with some help from me) proposed a good solution
> to handle local versus UTC time back in early 2000. Squeak was based on
> local time (both in the VM and in the image), so the idea was to provide
> a primitive with time and offset in an atomic call, such that UTC clock values
> would be available while providing the traditional local clock for compatibility
> in the existing image.
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-February/020249.html
>
> The primitiveUtcWithOffset primitive in the interpreter VM is based on Lex
> Spoon's original proposal.
> "Answer an array with UTC microseconds since the Posix epoch and
> the current seconds offset from GMT in the local time zone.
> This is a named (not numbered) primitive in the null module (ie the VM)"
>
> I take an interest in the topic because of this posting from 1999, which I
> personally consider to be the most important thing that I have contributed
> to Squeak over the years:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-December/005327.html
>
> Dave
>
>

You posted one year too soon ;)

Nicolas

Bert Freudenberg

Fixing time (was: Epoch returns local offset)

In reply to this post by David T. Lewis

On 18.05.2012, at 03:44, David T. Lewis wrote:

> On Thu, May 17, 2012 at 06:36:23PM -0700, Sean P. DeNigris wrote:
>>
>> David T. Lewis wrote
>>>
>>> it would be really nice to be able to simply refer people
>>> to the relevant Wikipedia page, where the concepts are properly documented
>>> and clearly explained.
>>>
>>
>> If you decide to go with the Unix epoch, I made the changes (which ended up
>> being minimal) in Pharo and all the relevant tests pass. The packages are in
>> the Pharo inbox - Kernel-SeanDeNigris.1087, KernelTests-SeanDeNigris.406,
>> Network-Mail-SeanDeNigris.11 & RecentSubmissions-SeanDeNigris.158
>
> Thanks!
>
> Dave

We need to do *something*.

I just discovered my vanilla Squeak image assumes the whole world lives in California summer time (UTC-7). Even though I fixed that a while ago.

This is because the #useLocale preference is off by default, so the time zone does not get set at startup. (In Etoys, which relies on correct UTC time stamps in some environments, the preference is enabled by default).

So for many, these two expressions return the wrong time:

DateAndTime now asUTC
DateAndTime now asUnixTime

and even just

DateAndTime now

is wrong because although it uses the correct local time, it has the wrong time zone.

So, at the very least, anyone who needs correct UTC times must enable #useLocale. Better yet, we should switch to a more robust setup.

- Bert -

Eliot Miranda-2

Re: [Pharo-project] Epoch returns local offset

In reply to this post by David T. Lewis

On Thu, May 17, 2012 at 5:59 PM, David T. Lewis <[hidden email]> wrote:

On Thu, May 17, 2012 at 04:01:11PM -0700, Eliot Miranda wrote:
> On Thu, May 17, 2012 at 10:42 AM, Bert Freudenberg <[hidden email]>wrote:
>
> > On 17.05.2012, at 19:29, Eliot Miranda wrote:
> >
> > What is ambiguous about the start of the 20-th century in GMT?
> >
> >
> > Nothing. But Smalltalk epoch was not defined in GMT. It's local time.
> >
>
> I'm not sure I buy that. Looking at Smalltalk-80 v2 the California
> timezone was hardwired in. So I think the epoch was in GMT and e.g. Time
> currentSeconds: #seconds answered the number of seconds from the GMT epoch.

If that were actually true, someone would have said so when they described
the meaning of the Smalltalk epoch. But they did not say so, and no such
definition exists anywhere except in the unsubstantiated opinions and
misconceptions of you, me, and everyone else on this list.

It exists in the Smalltalk-80 sources Time class>>currentTime: method (find attached; apologies for calling it currentSeconds: in my previous post):

'From Smalltalk-80, version 2, of April 1, 1983 on 31 May 1983 at 9:10:35 am'!

!Time class methodsFor: 'private'!

currentTime: formatted

"If formatted is #seconds, answer with the total seconds from Jan 1 1901

corrected for time zone and daylight savings time.

Otherwise, answer an array of (Date today, Time now).

m570 and m571 are time zone specific parameters, set for California."

| secondCount d dd t dfirst dlast m570 m571 |

secondCount _ LargePositiveInteger new: 4.

self secondClockInto: secondCount.

secondCount _ secondCount truncated.

m570 _ 16505.

m571 _ 305.

"adjust for time zone"

secondCount _

secondCount

+ ((m570 >= 0

ifTrue: [-1] "west"

ifFalse: [1] "east")

* (3600 * ((m570 bitAnd: 30720) bitShift: -11)

+ (60 * ((m571 bitAnd: 32256) bitShift: -9)))).

"Guess the number of days since Jan 1 1901."

d _ Date fromDays: secondCount // 86400.

"The formatted test makes it possible to skip some work if all you want is to correct

the total number of seconds. secondCount \\ 86400 is the number of seconds that

were left over from the estimate of days"

formatted==#seconds ifFalse: [t _ Time fromSeconds: secondCount \\ 86400].

"check for daylight savings time (DST). correct DST parameters for nonleap

years and round to previous Sunday if necessary"

"day of the year on or before which DST takes effect"

dfirst _ m570 bitAnd: 511.

(dfirst = 366

ifTrue: [false"DST not in effect"]

ifFalse: [(dd _ d day) >= (dfirst _ dfirst + d leap - 1)

ifTrue:

["day of the year on or before which DST ends"

dlast _ (m571 bitAnd: 511) + d leap - 1.

dd < dlast and:

[dd < ((Date newDay: dlast year: d year)

previous: #Sunday) day]]

ifFalse: ["possibly earlier than or at beginning of range"

dd >= ((Date newDay: dfirst year: d year)

previous: #Sunday) day]])

ifTrue: [formatted==#seconds

ifTrue: ["daylight savings time in effect. add an hour"

secondCount _ secondCount + 3600]

ifFalse: [t hours = 23

ifTrue:

[d _ d addDays: 1.

t hours: 0]

ifFalse: [t hours: t hours + 1]]].

formatted==#seconds

ifTrue: [^secondCount]

ifFalse: [^Array with: d with: t]! !

This seems pretty clear to me. The epoch is the start of the 20th century in GMT, and the currentTime answers the time in PST relative to the epoch in GMT. There's nothing opinionated or unsubstantiated about this code.

You have illustrated the problem perfectly: "I think the epoch was ..."
is your interpretation of what you think that someone might have intended,
which may or may not correspond with what was actually intended, if in fact
they intended anything at all, which most probably they did not. This is not
an issue that would have been on the forefront of anyone's consideration when
designing a personal computing system for the empowerment of individuals.

> certainly that's what the Cog VMs answer. But there's nothing to stop us
> firming up the definition. 1970 is a pretty arbitrary choice of epoch.
> The start of the 20th century has a certain elegance.

I would have prefered to propose the end of the Mayan calendar as the
more elegant reference point, but unfortunately the definition of this
point in time appears to suffer from some ambiguity also ;-)

> Even Microsoft have
> a nice epoch (the start of the gregorian calendar IIRC). Why slavishly
> follow unix when we have something distinctive and hard-wired into the VMs?
> Why not just define the Smalltalk epoch properly?

Because after more than 10 years of answering questions about this stuff
over and over, it would be really nice to be able to simply refer people
to the relevant Wikipedia page, where the concepts are properly documented
and clearly explained.

I do appreciate the distinctive nature of the Smalltalk epoch, and it can
be retained indefinitely for sentimental and historical reasons. But it
simply is not suitable for use as the basis for time measurement, however
much we might wish it were otherwise.

Dave

--
best,

Eliot

Time class-currentTime.st (2K) Download Attachment

Sean P. DeNigris

Re: [Pharo-project] Epoch returns local offset

Administrator

Eliot Miranda-2 wrote

This seems pretty clear to me. The epoch is the start of the 20th century
in GMT

If that is the definition, "DateAndTime epoch" has a bug. It simply tacks on the local offset (e.g "1901-01-01T00:00:00-04:00" on my machine). It should return "1901-01-01T00:00:00+00:00" or "1900-12-31T20:00:00-04:00", but "1901-01-01T00:00:00-04:00" is clearly wrong.

Also, "DateAndTime fromSeconds: 0" returns the same value. This is useless because a DateAndTime that is encoded as an offset must be relative to a fixed reference. The offset is not encoded, so if I "aDateAndTime asSeconds" (which also gives the incorrect result above), store it somewhere, go to a different timezone, and "DateAndTime fromSeconds: savedSeconds", I get a different result. For example:
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!"

Cheers,
Sean

David T. Lewis

Re: [Pharo-project] Epoch returns local offset

In reply to this post by Eliot Miranda-2

On Fri, May 18, 2012 at 10:22:12AM -0700, Eliot Miranda wrote:

> On Thu, May 17, 2012 at 5:59 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Thu, May 17, 2012 at 04:01:11PM -0700, Eliot Miranda wrote:
> > > On Thu, May 17, 2012 at 10:42 AM, Bert Freudenberg <[hidden email]
> > >wrote:
> > >
> > > > On 17.05.2012, at 19:29, Eliot Miranda wrote:
> > > >
> > > > What is ambiguous about the start of the 20-th century in GMT?
> > > >
> > > >
> > > > Nothing. But Smalltalk epoch was not defined in GMT. It's local time.
> > > >
> > >
> > > I'm not sure I buy that. Looking at Smalltalk-80 v2 the California
> > > timezone was hardwired in. So I think the epoch was in GMT and e.g. Time
> > > currentSeconds: #seconds answered the number of seconds from the GMT
> > epoch.
> >
> > If that were actually true, someone would have said so when they described
> > the meaning of the Smalltalk epoch. But they did not say so, and no such
> > definition exists anywhere except in the unsubstantiated opinions and
> > misconceptions of you, me, and everyone else on this list.
> >
>
> It exists in the Smalltalk-80 sources Time class>>currentTime: method (find
> attached; apologies for calling it currentSeconds: in my previous post):
>
> 'From Smalltalk-80, version 2, of April 1, 1983 on 31 May 1983 at 9:10:35
> am'!
>
> !Time class methodsFor: 'private'!
> currentTime: formatted
> "If formatted is #seconds, answer with the total seconds from Jan 1 1901
> corrected for time zone and daylight savings time.
> Otherwise, answer an array of (Date today, Time now).
> m570 and m571 are time zone specific parameters, set for California."
>

<snip>

> This seems pretty clear to me. The epoch is the start of the 20th century
> in GMT, and the currentTime answers the time in PST relative to the epoch
> in GMT. There's nothing opinionated or unsubstantiated about this code.
>

You're quite right about that, and thanks for providing the code reference.

I stand corrected - there is also an explicit reference to GMT on page 112
of the blue book (Time class>>timeWords).

I'll have to dig out an older Squeak image when I get home. I don't recall
that it ever worked this way, but I could be mistaken.

I do stand by my recommendation of the Posix epoch for use as a clearly
defined and well documented time basis.

Dave

Chris Muller-3

Re: Fixing time (was: Epoch returns local offset)

In reply to this post by Bert Freudenberg

I see useLocale, and it's false in standard Squeak 4.3. Not sure how
but when I look at DateAndTime's 'LocalTimeZone' class var, it's as if
your fixed startup method ran because it says 'Local Time' and has the
correct offset.

> So, at the very least, anyone who needs correct UTC times must enable #useLocale. Better yet, we should switch to a more robust setup.

Well Chronology is robust, and it appears just flipping a default
setting would "fix" it anyway..?

On Fri, May 18, 2012 at 5:38 AM, Bert Freudenberg <[hidden email]> wrote:

> On 18.05.2012, at 03:44, David T. Lewis wrote:
>
>> On Thu, May 17, 2012 at 06:36:23PM -0700, Sean P. DeNigris wrote:
>>>
>>> David T. Lewis wrote
>>>>
>>>> it would be really nice to be able to simply refer people
>>>> to the relevant Wikipedia page, where the concepts are properly documented
>>>> and clearly explained.
>>>>
>>>
>>> If you decide to go with the Unix epoch, I made the changes (which ended up
>>> being minimal) in Pharo and all the relevant tests pass. The packages are in
>>> the Pharo inbox - Kernel-SeanDeNigris.1087, KernelTests-SeanDeNigris.406,
>>> Network-Mail-SeanDeNigris.11 & RecentSubmissions-SeanDeNigris.158
>>
>> Thanks!
>>
>> Dave
>
>
> We need to do *something*.
>
> I just discovered my vanilla Squeak image assumes the whole world lives in California summer time (UTC-7). Even though I fixed that a while ago.
>
> This is because the #useLocale preference is off by default, so the time zone does not get set at startup. (In Etoys, which relies on correct UTC time stamps in some environments, the preference is enabled by default).
>
> So for many, these two expressions return the wrong time:
>
> DateAndTime now asUTC
> DateAndTime now asUnixTime
>
> and even just
>
> DateAndTime now
>
> is wrong because although it uses the correct local time, it has the wrong time zone.
>
> So, at the very least, anyone who needs correct UTC times must enable #useLocale. Better yet, we should switch to a more robust setup.
>
> - Bert -
>
>

Sean P. DeNigris

Re: Fixing time (was: Epoch returns local offset)

Administrator

Chris Muller-3 wrote

Well Chronology is robust, and it appears just flipping a default
setting would "fix" it anyway..?

#useLocale will make sure that your offset is correct for your current location, which is important, but tangential to the subject of this thread i.e. "what should the epoch be and how should the local offset effect it?"

HTH,
Sean

Cheers,
Sean

Bert Freudenberg

Re: [Pharo-project] Epoch returns local offset

In reply to this post by Eliot Miranda-2

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 -

Bert Freudenberg

Re: Fixing time (was: Epoch returns local offset)

In reply to this post by Chris Muller-3

On 18.05.2012, at 21:12, Chris Muller wrote:

> I see useLocale, and it's false in standard Squeak 4.3. Not sure how
> but when I look at DateAndTime's 'LocalTimeZone' class var, it's as if
> your fixed startup method ran because it says 'Local Time' and has the
> correct offset.

You accidentally live in the same timezone as the guy who ran that code last before releasing an image.

>> So, at the very least, anyone who needs correct UTC times must enable #useLocale. Better yet, we should switch to a more robust setup.
>
> Well Chronology is robust, and it appears just flipping a default
> setting would "fix" it anyway..?

It's not robust in that the timezone offset is only read on startup. If you have the image running for extended periods you may miss DST changes.

That's what the new time primitive is for, which answers both current UTC time and current timezone offset.

Of course, when we fix that we will have to look out for clients that mistakenly expect local time to be monotonous.

- Bert -

Douglas Brebner

Re: Fixing time

On 18/05/2012 20:39, Bert Freudenberg wrote:
> It's not robust in that the timezone offset is only read on startup.
> If you have the image running for extended periods you may miss DST
> changes.

It'll also fail to detect if the system timezone is changed due to
physically moving to another zone (e.g. a laptop, smartphone or
something even nastier)

David T. Lewis

Re: [Pharo-project] Epoch returns local offset

In reply to this post by Nicolas Cellier

On Fri, May 18, 2012 at 11:12:59AM +0200, Nicolas Cellier wrote:

> 2012/5/18 David T. Lewis <[hidden email]>:
> >
> > ?http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-December/005327.html
> >
> > Dave
> >
> >
> You posted one year too soon ;)
>
> Nicolas

Well, this was all done at the height of the worldwide Y2K frenzy, so I
felt that I was under great pressure to get the package released before
all of the world's computers melted down into puddles of molten silicon.

;)

Dave

David T. Lewis

Re: [Pharo-project] Epoch returns local offset

In reply to this post by Bert Freudenberg

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 ...

Dave