Re: [squeak-dev] Daily Commit Log

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

Re: [squeak-dev] Daily Commit Log

Eliot Miranda-2
 
Hi David,

    any chance of getting you to retract this?  The Cog VM has 64-bit UTC & local microseconds from the Smalltalk epoch (1901), which are hence easier to use as a basis for the Squeak clock and still last for ~ 54,000 years.  I'd like to see the Cog and standard VMs converge on a primitive set.  This is an issue for me since changing the epoch is, I think, an unnecessary change.

best
Eliot

On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:

http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html

Name: Kernel-dtl.476
Ancestors: Kernel-eem.475

Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset for access to microsecond clock primitives available in newer Squeak VMs.

primMicrosecondClock provides a system clock with nominal microsecond precision.

primUtcWithOffset answers UTC time as microseconds since the Posix epoch and offset as seconds offset from GMT. The Squeak clock is traditionally implemented in terms of platform local time. Use of UTC time and offset is advantageous if time zones and daylight saving time offsets are to be considered.

Example:
{ Time primMillisecondClock .
  Time primMicrosecondClock .
  Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304 -14400))


=============================================


Reply | Threaded
Open this post in threaded view
|

Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

David T. Lewis
 
Eliot,

Yes, it can be retracted. I may not get to it for a few days so feel
free to do so on my behalf. I introduced the change in trunk to put
some visibility on the new primitives, which appears to have achieved
the intended purpose ;)

With respect to the Squeak epoch, we do have an issue that needs to
be clarified. In the Squeak implementation, we have the 1901 epoch,
but AFAIK there is no specification of the time zone in which the epoch
is defined. In the Squeak implementation, local time has consistently
been used in the platform interface, and the actual values of the
Squeak clock for any real point in time are different depending on
the time zone in which the image happens to be running.

To put it another way, there is no such thing as "UTC & local
microseconds from the Smalltalk epoch" unless there is a clearly
defined transformation between the Smalltalk epoch and the posix
epoch, and in practice (in Squeak at least) this is not the case.
Midnight on January 1, 1901 in Palo Alto, California was a different
point in time from midnight January 1, 1901 in London, and I cannot
determine which of the two was the "real" Smalltalk epoch.

This begs the question of why, in implementing the interface to
the underlying platform, we would *not* want use the posix epoch
as a reference point. The Posix epoch is well defined, well documented,
well understood, and easily translated to any existing definition of
the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
defined, poorly documented, and widely misunderstood.

Dave

On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:

>  
> Hi David,
>
>     any chance of getting you to retract this?  The Cog VM has 64-bit UTC &
> local microseconds from the Smalltalk epoch (1901), which are hence easier
> to use as a basis for the Squeak clock and still last for ~ 54,000 years.
>  I'd like to see the Cog and standard VMs converge on a primitive set.  This
> is an issue for me since changing the epoch is, I think, an unnecessary
> change.
>
> best
> Eliot
>
> On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
>
> > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
> > hours:
> >
> >
> > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
> >
> > Name: Kernel-dtl.476
> > Ancestors: Kernel-eem.475
> >
> > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset for
> > access to microsecond clock primitives available in newer Squeak VMs.
> >
> > primMicrosecondClock provides a system clock with nominal microsecond
> > precision.
> >
> > primUtcWithOffset answers UTC time as microseconds since the Posix epoch
> > and offset as seconds offset from GMT. The Squeak clock is traditionally
> > implemented in terms of platform local time. Use of UTC time and offset is
> > advantageous if time zones and daylight saving time offsets are to be
> > considered.
> >
> > Example:
> > { Time primMillisecondClock .
> >   Time primMicrosecondClock .
> >   Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
> > -14400))
> >
> >
> > =============================================
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

Bert Freudenberg


On 23.08.2010, at 04:39, David T. Lewis wrote:

>
> Eliot,
>
> Yes, it can be retracted. I may not get to it for a few days so feel
> free to do so on my behalf. I introduced the change in trunk to put
> some visibility on the new primitives, which appears to have achieved
> the intended purpose ;)
>
> With respect to the Squeak epoch, we do have an issue that needs to
> be clarified. In the Squeak implementation, we have the 1901 epoch,
> but AFAIK there is no specification of the time zone in which the epoch
> is defined.

It is defined as local time.

DateAndTime epoch "in Germany (!)"
        1901-01-01T00:00:00+02:00

DateAndTime unixEpoch
        1970-01-01T00:00:00+00:00

> In the Squeak implementation, local time has consistently
> been used in the platform interface, and the actual values of the
> Squeak clock for any real point in time are different depending on
> the time zone in which the image happens to be running.

Right.

> To put it another way, there is no such thing as "UTC & local
> microseconds from the Smalltalk epoch" unless there is a clearly
> defined transformation between the Smalltalk epoch and the posix
> epoch, and in practice (in Squeak at least) this is not the case.

It is, you just need to know the local UTC offset.

> Midnight on January 1, 1901 in Palo Alto, California was a different
> point in time from midnight January 1, 1901 in London, and I cannot
> determine which of the two was the "real" Smalltalk epoch.

Both ;)

> This begs the question of why, in implementing the interface to
> the underlying platform, we would *not* want use the posix epoch
> as a reference point. The Posix epoch is well defined, well documented,
> well understood, and easily translated to any existing definition of
> the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
> defined, poorly documented, and widely misunderstood.
>
> Dave

Agreed. +1 for using POSIX time in the prim. That way, we at least share the problems of virtually all other computer systems, so the errors cancel out ;)

However, you still want to access local time. That means you need to know the UTC offset. But any two of UTC, local time, and time zone offset for the current point in time allow to determine the third, so which two to base your calculations on is pretty much arbitrary.

The only real fault of the current implementation is that the time zone is only fetched on image startup. That means it won't pick up DST changes. Having a primitive that always fetches both utc+local time avoids that, which is precisely what is implemented in Cog, IIUC.

OTOH I agree that even Eliot's choice of words below is ambiguous. What he means (I think) with "UTC microseconds from Smalltalk epoch" is "Smalltalk epoch in UTC" so that would be "(posixTime + 2,177,452,800) * 1,000,000" and "local microseconds from Smalltalk" would be "(posixTime + utcToLocalOffsetInSeconds + 2,177,452,800) * 1,000,000". That's because
        ('1970-01-01T00:00:00+00:00' asDateAndTime - '1901-01-01T00:00:00+00:00' asDateAndTime) asSeconds asStringWithCommas
is
        '2,177,452,800'

It would be a lot easier if we could say "it's posix time as microseconds" ;)

- Bert -

PS: I think the correct implementation for ZipArchiveMember>>unixToSqueakTime: would be

        ^DateAndTime unixEpoch asSeconds + unixTime - DateAndTime epoch asSeconds

where "DateAndTime unixEpoch" is a constant but "DateAndTime epoch" (counter-intuitively) is not.


> On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
>>
>> Hi David,
>>
>>    any chance of getting you to retract this?  The Cog VM has 64-bit UTC &
>> local microseconds from the Smalltalk epoch (1901), which are hence easier
>> to use as a basis for the Squeak clock and still last for ~ 54,000 years.
>> I'd like to see the Cog and standard VMs converge on a primitive set.  This
>> is an issue for me since changing the epoch is, I think, an unnecessary
>> change.
>>
>> best
>> Eliot
>>
>> On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
>>
>>> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
>>> hours:
>>>
>>>
>>> http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
>>>
>>> Name: Kernel-dtl.476
>>> Ancestors: Kernel-eem.475
>>>
>>> Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset for
>>> access to microsecond clock primitives available in newer Squeak VMs.
>>>
>>> primMicrosecondClock provides a system clock with nominal microsecond
>>> precision.
>>>
>>> primUtcWithOffset answers UTC time as microseconds since the Posix epoch
>>> and offset as seconds offset from GMT. The Squeak clock is traditionally
>>> implemented in terms of platform local time. Use of UTC time and offset is
>>> advantageous if time zones and daylight saving time offsets are to be
>>> considered.
>>>
>>> Example:
>>> { Time primMillisecondClock .
>>>  Time primMicrosecondClock .
>>>  Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
>>> -14400))
>>>
>>>
>>> =============================================

Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

Eliot Miranda-2
In reply to this post by David T. Lewis
 


On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <[hidden email]> wrote:

Eliot,

Yes, it can be retracted. I may not get to it for a few days so feel
free to do so on my behalf. I introduced the change in trunk to put
some visibility on the new primitives, which appears to have achieved
the intended purpose ;)

With respect to the Squeak epoch, we do have an issue that needs to
be clarified. In the Squeak implementation, we have the 1901 epoch,
but AFAIK there is no specification of the time zone in which the epoch
is defined. In the Squeak implementation, local time has consistently
been used in the platform interface, and the actual values of the
Squeak clock for any real point in time are different depending on
the time zone in which the image happens to be running.

It's implicit that it is GMT/UTC.  So the Squeak epoch is the start of 1901 in Greenwich.

To put it another way, there is no such thing as "UTC & local
microseconds from the Smalltalk epoch" unless there is a clearly
defined transformation between the Smalltalk epoch and the posix
epoch, and in practice (in Squeak at least) this is not the case.
Midnight on January 1, 1901 in Palo Alto, California was a different
point in time from midnight January 1, 1901 in London, and I cannot
determine which of the two was the "real" Smalltalk epoch.

The latter is the only one that makes good sense.
 
This begs the question of why, in implementing the interface to
the underlying platform, we would *not* want use the posix epoch
as a reference point. The Posix epoch is well defined, well documented,
well understood, and easily translated to any existing definition of
the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
defined, poorly documented, and widely misunderstood.

I think its easy to fix; just define it to be the start of the 20th century in UTC.  That's what we did with VW and its easy to do with Squeak.  For me backwards compatibility pushes strongly for keeping with the Squeak epoch, i.e. Time seconds = Time milliseconds / 1000000.

best,
Eliot
 

Dave

On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
>
> Hi David,
>
>     any chance of getting you to retract this?  The Cog VM has 64-bit UTC &
> local microseconds from the Smalltalk epoch (1901), which are hence easier
> to use as a basis for the Squeak clock and still last for ~ 54,000 years.
>  I'd like to see the Cog and standard VMs converge on a primitive set.  This
> is an issue for me since changing the epoch is, I think, an unnecessary
> change.
>
> best
> Eliot
>
> On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
>
> > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
> > hours:
> >
> >
> > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
> >
> > Name: Kernel-dtl.476
> > Ancestors: Kernel-eem.475
> >
> > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset for
> > access to microsecond clock primitives available in newer Squeak VMs.
> >
> > primMicrosecondClock provides a system clock with nominal microsecond
> > precision.
> >
> > primUtcWithOffset answers UTC time as microseconds since the Posix epoch
> > and offset as seconds offset from GMT. The Squeak clock is traditionally
> > implemented in terms of platform local time. Use of UTC time and offset is
> > advantageous if time zones and daylight saving time offsets are to be
> > considered.
> >
> > Example:
> > { Time primMillisecondClock .
> >   Time primMicrosecondClock .
> >   Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
> > -14400))
> >
> >
> > =============================================
> >
> >


Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

Nicolas Cellier

2010/8/23 Eliot Miranda <[hidden email]>:

>
>
>
> On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <[hidden email]> wrote:
>>
>> Eliot,
>>
>> Yes, it can be retracted. I may not get to it for a few days so feel
>> free to do so on my behalf. I introduced the change in trunk to put
>> some visibility on the new primitives, which appears to have achieved
>> the intended purpose ;)
>>
>> With respect to the Squeak epoch, we do have an issue that needs to
>> be clarified. In the Squeak implementation, we have the 1901 epoch,
>> but AFAIK there is no specification of the time zone in which the epoch
>> is defined. In the Squeak implementation, local time has consistently
>> been used in the platform interface, and the actual values of the
>> Squeak clock for any real point in time are different depending on
>> the time zone in which the image happens to be running.
>
> It's implicit that it is GMT/UTC.  So the Squeak epoch is the start of 1901 in Greenwich.
>>
>> To put it another way, there is no such thing as "UTC & local
>> microseconds from the Smalltalk epoch" unless there is a clearly
>> defined transformation between the Smalltalk epoch and the posix
>> epoch, and in practice (in Squeak at least) this is not the case.
>> Midnight on January 1, 1901 in Palo Alto, California was a different
>> point in time from midnight January 1, 1901 in London, and I cannot
>> determine which of the two was the "real" Smalltalk epoch.
>
> The latter is the only one that makes good sense.
>
>>
>> This begs the question of why, in implementing the interface to
>> the underlying platform, we would *not* want use the posix epoch
>> as a reference point. The Posix epoch is well defined, well documented,
>> well understood, and easily translated to any existing definition of
>> the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
>> defined, poorly documented, and widely misunderstood.
>
> I think its easy to fix; just define it to be the start of the 20th century in UTC.  That's what we did with VW and its easy to do with Squeak.  For me backwards compatibility pushes strongly for keeping with the Squeak epoch, i.e. Time seconds = Time milliseconds / 1000000.

Or maybe milliseconds / 1000 or microseconds / 1000000 ?

> best,
> Eliot
>
>>
>> Dave
>>
>> On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
>> >
>> > Hi David,
>> >
>> >     any chance of getting you to retract this?  The Cog VM has 64-bit UTC &
>> > local microseconds from the Smalltalk epoch (1901), which are hence easier
>> > to use as a basis for the Squeak clock and still last for ~ 54,000 years.
>> >  I'd like to see the Cog and standard VMs converge on a primitive set.  This
>> > is an issue for me since changing the epoch is, I think, an unnecessary
>> > change.
>> >
>> > best
>> > Eliot
>> >
>> > On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
>> >
>> > > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
>> > > hours:
>> > >
>> > >
>> > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
>> > >
>> > > Name: Kernel-dtl.476
>> > > Ancestors: Kernel-eem.475
>> > >
>> > > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset for
>> > > access to microsecond clock primitives available in newer Squeak VMs.
>> > >
>> > > primMicrosecondClock provides a system clock with nominal microsecond
>> > > precision.
>> > >
>> > > primUtcWithOffset answers UTC time as microseconds since the Posix epoch
>> > > and offset as seconds offset from GMT. The Squeak clock is traditionally
>> > > implemented in terms of platform local time. Use of UTC time and offset is
>> > > advantageous if time zones and daylight saving time offsets are to be
>> > > considered.
>> > >
>> > > Example:
>> > > { Time primMillisecondClock .
>> > >   Time primMicrosecondClock .
>> > >   Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
>> > > -14400))
>> > >
>> > >
>> > > =============================================
>> > >
>> > >
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

Eliot Miranda-2
 


On Mon, Aug 23, 2010 at 11:32 AM, Nicolas Cellier <[hidden email]> wrote:

2010/8/23 Eliot Miranda <[hidden email]>:
>
>
>
> On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <[hidden email]> wrote:
>>
>> Eliot,
>>
>> Yes, it can be retracted. I may not get to it for a few days so feel
>> free to do so on my behalf. I introduced the change in trunk to put
>> some visibility on the new primitives, which appears to have achieved
>> the intended purpose ;)
>>
>> With respect to the Squeak epoch, we do have an issue that needs to
>> be clarified. In the Squeak implementation, we have the 1901 epoch,
>> but AFAIK there is no specification of the time zone in which the epoch
>> is defined. In the Squeak implementation, local time has consistently
>> been used in the platform interface, and the actual values of the
>> Squeak clock for any real point in time are different depending on
>> the time zone in which the image happens to be running.
>
> It's implicit that it is GMT/UTC.  So the Squeak epoch is the start of 1901 in Greenwich.
>>
>> To put it another way, there is no such thing as "UTC & local
>> microseconds from the Smalltalk epoch" unless there is a clearly
>> defined transformation between the Smalltalk epoch and the posix
>> epoch, and in practice (in Squeak at least) this is not the case.
>> Midnight on January 1, 1901 in Palo Alto, California was a different
>> point in time from midnight January 1, 1901 in London, and I cannot
>> determine which of the two was the "real" Smalltalk epoch.
>
> The latter is the only one that makes good sense.
>
>>
>> This begs the question of why, in implementing the interface to
>> the underlying platform, we would *not* want use the posix epoch
>> as a reference point. The Posix epoch is well defined, well documented,
>> well understood, and easily translated to any existing definition of
>> the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
>> defined, poorly documented, and widely misunderstood.
>
> I think its easy to fix; just define it to be the start of the 20th century in UTC.  That's what we did with VW and its easy to do with Squeak.  For me backwards compatibility pushes strongly for keeping with the Squeak epoch, i.e. Time seconds = Time milliseconds / 1000000.

Or maybe milliseconds / 1000 or microseconds / 1000000 ?

Doh!  Indeed I meant "Time seconds = Time microseconds // 1000000".  Monday mornings ;)
 

> best,
> Eliot
>
>>
>> Dave
>>
>> On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
>> >
>> > Hi David,
>> >
>> >     any chance of getting you to retract this?  The Cog VM has 64-bit UTC &
>> > local microseconds from the Smalltalk epoch (1901), which are hence easier
>> > to use as a basis for the Squeak clock and still last for ~ 54,000 years.
>> >  I'd like to see the Cog and standard VMs converge on a primitive set.  This
>> > is an issue for me since changing the epoch is, I think, an unnecessary
>> > change.
>> >
>> > best
>> > Eliot
>> >
>> > On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
>> >
>> > > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
>> > > hours:
>> > >
>> > >
>> > > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
>> > >
>> > > Name: Kernel-dtl.476
>> > > Ancestors: Kernel-eem.475
>> > >
>> > > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset for
>> > > access to microsecond clock primitives available in newer Squeak VMs.
>> > >
>> > > primMicrosecondClock provides a system clock with nominal microsecond
>> > > precision.
>> > >
>> > > primUtcWithOffset answers UTC time as microseconds since the Posix epoch
>> > > and offset as seconds offset from GMT. The Squeak clock is traditionally
>> > > implemented in terms of platform local time. Use of UTC time and offset is
>> > > advantageous if time zones and daylight saving time offsets are to be
>> > > considered.
>> > >
>> > > Example:
>> > > { Time primMillisecondClock .
>> > >   Time primMicrosecondClock .
>> > >   Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
>> > > -14400))
>> > >
>> > >
>> > > =============================================
>> > >
>> > >
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

David T. Lewis
In reply to this post by Eliot Miranda-2
 
Eliot,

I am afraid that I may have misunderstood your original request
to retract the change.

I assumed that you were refering to Time class>>primUtcWithOffset
that I had added to trunk (and I did remove that method), but
in rereading your note I think you may have been referring to
the earlier VMMaker updates that introduced the primitives
#primitiveMicrosecondClock and #primitiveUtcWithOffset. In
particular, #primitiveMicrosecondClock seems similar to the
Cog primitives, which include #primitiveUTCMicrosecondClock
and #primitiveLocalMicrosecondClock.

Apologies for my misunderstanding, but can you please clarify
which methods you were suggesting should be retracted?

        Interpreter>>primitiveMicrosecondClock
        Interpreter>>primitiveUtcWithOffset
        Time class>>primMicrosecondClock
        Time class>>primUtcWithOffset

Thanks,
Dave


On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote:

>  
> On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <[hidden email]> wrote:
>
> >
> > Eliot,
> >
> > Yes, it can be retracted. I may not get to it for a few days so feel
> > free to do so on my behalf. I introduced the change in trunk to put
> > some visibility on the new primitives, which appears to have achieved
> > the intended purpose ;)
> >
> > With respect to the Squeak epoch, we do have an issue that needs to
> > be clarified. In the Squeak implementation, we have the 1901 epoch,
> > but AFAIK there is no specification of the time zone in which the epoch
> > is defined. In the Squeak implementation, local time has consistently
> > been used in the platform interface, and the actual values of the
> > Squeak clock for any real point in time are different depending on
> > the time zone in which the image happens to be running.
> >
>
> It's implicit that it is GMT/UTC.  So the Squeak epoch is the start of 1901
> in Greenwich.
>
> To put it another way, there is no such thing as "UTC & local
> > microseconds from the Smalltalk epoch" unless there is a clearly
> > defined transformation between the Smalltalk epoch and the posix
> > epoch, and in practice (in Squeak at least) this is not the case.
> > Midnight on January 1, 1901 in Palo Alto, California was a different
> > point in time from midnight January 1, 1901 in London, and I cannot
> > determine which of the two was the "real" Smalltalk epoch.
> >
>
> The latter is the only one that makes good sense.
>
>
> > This begs the question of why, in implementing the interface to
> > the underlying platform, we would *not* want use the posix epoch
> > as a reference point. The Posix epoch is well defined, well documented,
> > well understood, and easily translated to any existing definition of
> > the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
> > defined, poorly documented, and widely misunderstood.
> >
>
> I think its easy to fix; just define it to be the start of the 20th century
> in UTC.  That's what we did with VW and its easy to do with Squeak.  For me
> backwards compatibility pushes strongly for keeping with the Squeak epoch,
> i.e. Time seconds = Time milliseconds / 1000000.
>
> best,
> Eliot
>
>
> >
> > Dave
> >
> > On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
> > >
> > > Hi David,
> > >
> > >     any chance of getting you to retract this?  The Cog VM has 64-bit UTC
> > &
> > > local microseconds from the Smalltalk epoch (1901), which are hence
> > easier
> > > to use as a basis for the Squeak clock and still last for ~ 54,000 years.
> > >  I'd like to see the Cog and standard VMs converge on a primitive set.
> >  This
> > > is an issue for me since changing the epoch is, I think, an unnecessary
> > > change.
> > >
> > > best
> > > Eliot
> > >
> > > On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
> > >
> > > > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
> > > > hours:
> > > >
> > > >
> > > >
> > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
> > > >
> > > > Name: Kernel-dtl.476
> > > > Ancestors: Kernel-eem.475
> > > >
> > > > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset
> > for
> > > > access to microsecond clock primitives available in newer Squeak VMs.
> > > >
> > > > primMicrosecondClock provides a system clock with nominal microsecond
> > > > precision.
> > > >
> > > > primUtcWithOffset answers UTC time as microseconds since the Posix
> > epoch
> > > > and offset as seconds offset from GMT. The Squeak clock is
> > traditionally
> > > > implemented in terms of platform local time. Use of UTC time and offset
> > is
> > > > advantageous if time zones and daylight saving time offsets are to be
> > > > considered.
> > > >
> > > > Example:
> > > > { Time primMillisecondClock .
> > > >   Time primMicrosecondClock .
> > > >   Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
> > > > -14400))
> > > >
> > > >
> > > > =============================================
> > > >
> > > >
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

Eliot Miranda-2
 
Hi David,

On Tue, Aug 24, 2010 at 5:24 AM, David T. Lewis <[hidden email]> wrote:
Eliot,

I am afraid that I may have misunderstood your original request
to retract the change.

I assumed that you were refering to Time class>>primUtcWithOffset
that I had added to trunk (and I did remove that method), but
in rereading your note I think you may have been referring to
the earlier VMMaker updates that introduced the primitives
#primitiveMicrosecondClock and #primitiveUtcWithOffset. In
particular, #primitiveMicrosecondClock seems similar to the
Cog primitives, which include #primitiveUTCMicrosecondClock
and #primitiveLocalMicrosecondClock.

Apologies for my misunderstanding, but can you please clarify
which methods you were suggesting should be retracted?

       Interpreter>>primitiveMicrosecondClock
       Interpreter>>primitiveUtcWithOffset
       Time class>>primMicrosecondClock
       Time class>>primUtcWithOffset

If primitiveMicrosecondClock answers 64-bit UTC microseconds since 1901 this is the same as Cog's primitiveUTCMicrosecondClock and should be retained.  It also needs a 64-bit local microseconds since 1901 which would be the same as Cog's primitiveLocalMicrosecondClock and a primitiveSignalAtUTCMicroseconds which is for 64-bit microseconds since 1901 what primitiveSignalAtMilliseconds is for 30-bit wrapping milliseconds (again see Cog).  We then need to agree on some primitive numbers or primitive names.  In Cog these three are

(240 primitiveUTCMicrosecondClock) "was serial port primitive"
(241 primitiveLocalMicrosecondClock) "was serial port primitive"
(242 primitiveSignalAtUTCMicroseconds)

Cog also has
(243 primitiveUpdateTimezone) "primStringtranslatefromtotable"

primitiveUpdateTimezone
"Update the VMs notion of the current timezone.  The VM sets its notion
of the timezone once at start-up.  If one wants the VM to keep its notion
up-to-date arrange to invoke this primitive periodically."
self ioUpdateVMTimezone

which causes the VM to reevaluate the delta between UTC and local microseconds.

With these four one has a non-wrapping synchronised timebase with potentially microsecond resolution that marries well with Squeak's 64-bit integer support.  This approach worked very well for VisualWorks where we got rid of lots of customer problems every 49.7 days (2^32 milliseconds).  There has been some concern expressed about the performance impact of long integers but at least in VW that simply wasn't an issue.

best
Eliot  


Thanks,
Dave


On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote:
>
> On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <[hidden email]> wrote:
>
> >
> > Eliot,
> >
> > Yes, it can be retracted. I may not get to it for a few days so feel
> > free to do so on my behalf. I introduced the change in trunk to put
> > some visibility on the new primitives, which appears to have achieved
> > the intended purpose ;)
> >
> > With respect to the Squeak epoch, we do have an issue that needs to
> > be clarified. In the Squeak implementation, we have the 1901 epoch,
> > but AFAIK there is no specification of the time zone in which the epoch
> > is defined. In the Squeak implementation, local time has consistently
> > been used in the platform interface, and the actual values of the
> > Squeak clock for any real point in time are different depending on
> > the time zone in which the image happens to be running.
> >
>
> It's implicit that it is GMT/UTC.  So the Squeak epoch is the start of 1901
> in Greenwich.
>
> To put it another way, there is no such thing as "UTC & local
> > microseconds from the Smalltalk epoch" unless there is a clearly
> > defined transformation between the Smalltalk epoch and the posix
> > epoch, and in practice (in Squeak at least) this is not the case.
> > Midnight on January 1, 1901 in Palo Alto, California was a different
> > point in time from midnight January 1, 1901 in London, and I cannot
> > determine which of the two was the "real" Smalltalk epoch.
> >
>
> The latter is the only one that makes good sense.
>
>
> > This begs the question of why, in implementing the interface to
> > the underlying platform, we would *not* want use the posix epoch
> > as a reference point. The Posix epoch is well defined, well documented,
> > well understood, and easily translated to any existing definition of
> > the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
> > defined, poorly documented, and widely misunderstood.
> >
>
> I think its easy to fix; just define it to be the start of the 20th century
> in UTC.  That's what we did with VW and its easy to do with Squeak.  For me
> backwards compatibility pushes strongly for keeping with the Squeak epoch,
> i.e. Time seconds = Time milliseconds / 1000000.
>
> best,
> Eliot
>
>
> >
> > Dave
> >
> > On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
> > >
> > > Hi David,
> > >
> > >     any chance of getting you to retract this?  The Cog VM has 64-bit UTC
> > &
> > > local microseconds from the Smalltalk epoch (1901), which are hence
> > easier
> > > to use as a basis for the Squeak clock and still last for ~ 54,000 years.
> > >  I'd like to see the Cog and standard VMs converge on a primitive set.
> >  This
> > > is an issue for me since changing the epoch is, I think, an unnecessary
> > > change.
> > >
> > > best
> > > Eliot
> > >
> > > On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]> wrote:
> > >
> > > > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
> > > > hours:
> > > >
> > > >
> > > >
> > http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
> > > >
> > > > Name: Kernel-dtl.476
> > > > Ancestors: Kernel-eem.475
> > > >
> > > > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset
> > for
> > > > access to microsecond clock primitives available in newer Squeak VMs.
> > > >
> > > > primMicrosecondClock provides a system clock with nominal microsecond
> > > > precision.
> > > >
> > > > primUtcWithOffset answers UTC time as microseconds since the Posix
> > epoch
> > > > and offset as seconds offset from GMT. The Squeak clock is
> > traditionally
> > > > implemented in terms of platform local time. Use of UTC time and offset
> > is
> > > > advantageous if time zones and daylight saving time offsets are to be
> > > > considered.
> > > >
> > > > Example:
> > > > { Time primMillisecondClock .
> > > >   Time primMicrosecondClock .
> > > >   Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
> > > > -14400))
> > > >
> > > >
> > > > =============================================
> > > >
> > > >
> >
> >


Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock

Andreas.Raab
 
On 8/24/2010 9:43 AM, Eliot Miranda wrote:
> With these four one has a non-wrapping synchronised timebase with
> potentially microsecond resolution that marries well with Squeak's
> 64-bit integer support.  This approach worked very well for VisualWorks
> where we got rid of lots of customer problems every 49.7 days (2^32
> milliseconds).  There has been some concern expressed about the
> performance impact of long integers but at least in VW that simply
> wasn't an issue.

For general purpose apps, sure. Remember that my concern is what the
effect of switching to largeint arithmetic is on our routers which
time-stamp in and outgoing packets at several points so that we can keep
track of latencies and where they're introduced. I will absolutely
believe that in "average" use there's not going to be an impact, but I
don't think that what we're doing (timestamping millions of times per
second) can be exactly considered average here :-) You'll recall that
the introduction of the jiffy clock was in response to the server
spending some 20% or so in gettimeofday...

Cheers,
   - Andreas

>
> best
> Eliot
>
>
>     Thanks,
>     Dave
>
>
>     On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote:
>      >
>      > On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >
>      > >
>      > > Eliot,
>      > >
>      > > Yes, it can be retracted. I may not get to it for a few days so
>     feel
>      > > free to do so on my behalf. I introduced the change in trunk to put
>      > > some visibility on the new primitives, which appears to have
>     achieved
>      > > the intended purpose ;)
>      > >
>      > > With respect to the Squeak epoch, we do have an issue that needs to
>      > > be clarified. In the Squeak implementation, we have the 1901 epoch,
>      > > but AFAIK there is no specification of the time zone in which
>     the epoch
>      > > is defined. In the Squeak implementation, local time has
>     consistently
>      > > been used in the platform interface, and the actual values of the
>      > > Squeak clock for any real point in time are different depending on
>      > > the time zone in which the image happens to be running.
>      > >
>      >
>      > It's implicit that it is GMT/UTC.  So the Squeak epoch is the
>     start of 1901
>      > in Greenwich.
>      >
>      > To put it another way, there is no such thing as "UTC & local
>      > > microseconds from the Smalltalk epoch" unless there is a clearly
>      > > defined transformation between the Smalltalk epoch and the posix
>      > > epoch, and in practice (in Squeak at least) this is not the case.
>      > > Midnight on January 1, 1901 in Palo Alto, California was a
>     different
>      > > point in time from midnight January 1, 1901 in London, and I cannot
>      > > determine which of the two was the "real" Smalltalk epoch.
>      > >
>      >
>      > The latter is the only one that makes good sense.
>      >
>      >
>      > > This begs the question of why, in implementing the interface to
>      > > the underlying platform, we would *not* want use the posix epoch
>      > > as a reference point. The Posix epoch is well defined, well
>     documented,
>      > > well understood, and easily translated to any existing
>     definition of
>      > > the Smalltalk epoch. In contrast, the Smalltalk epoch is
>     ambiguously
>      > > defined, poorly documented, and widely misunderstood.
>      > >
>      >
>      > I think its easy to fix; just define it to be the start of the
>     20th century
>      > in UTC.  That's what we did with VW and its easy to do with
>     Squeak.  For me
>      > backwards compatibility pushes strongly for keeping with the
>     Squeak epoch,
>      > i.e. Time seconds = Time milliseconds / 1000000.
>      >
>      > best,
>      > Eliot
>      >
>      >
>      > >
>      > > Dave
>      > >
>      > > On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
>      > > >
>      > > > Hi David,
>      > > >
>      > > >     any chance of getting you to retract this?  The Cog VM
>     has 64-bit UTC
>      > > &
>      > > > local microseconds from the Smalltalk epoch (1901), which are
>     hence
>      > > easier
>      > > > to use as a basis for the Squeak clock and still last for ~
>     54,000 years.
>      > > >  I'd like to see the Cog and standard VMs converge on a
>     primitive set.
>      > >  This
>      > > > is an issue for me since changing the epoch is, I think, an
>     unnecessary
>      > > > change.
>      > > >
>      > > > best
>      > > > Eliot
>      > > >
>      > > > On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      > > >
>      > > > > Changes to Trunk (http://source.squeak.org/trunk.html) in
>     the last 24
>      > > > > hours:
>      > > > >
>      > > > >
>      > > > >
>      > >
>     http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
>      > > > >
>      > > > > Name: Kernel-dtl.476
>      > > > > Ancestors: Kernel-eem.475
>      > > > >
>      > > > > Add Time class>>primMicrosecondClock and Time
>     class>>primUtcWithOffset
>      > > for
>      > > > > access to microsecond clock primitives available in newer
>     Squeak VMs.
>      > > > >
>      > > > > primMicrosecondClock provides a system clock with nominal
>     microsecond
>      > > > > precision.
>      > > > >
>      > > > > primUtcWithOffset answers UTC time as microseconds since
>     the Posix
>      > > epoch
>      > > > > and offset as seconds offset from GMT. The Squeak clock is
>      > > traditionally
>      > > > > implemented in terms of platform local time. Use of UTC
>     time and offset
>      > > is
>      > > > > advantageous if time zones and daylight saving time offsets
>     are to be
>      > > > > considered.
>      > > > >
>      > > > > Example:
>      > > > > { Time primMillisecondClock .
>      > > > >   Time primMicrosecondClock .
>      > > > >   Time primUtcWithOffset } ==> #(6932757 6932757830
>     #(1281815075538304
>      > > > > -14400))
>      > > > >
>      > > > >
>      > > > > =============================================
>      > > > >
>      > > > >
>      > >
>      > >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock

Eliot Miranda-2
 


On Tue, Aug 24, 2010 at 10:18 AM, Andreas Raab <[hidden email]> wrote:

On 8/24/2010 9:43 AM, Eliot Miranda wrote:
With these four one has a non-wrapping synchronised timebase with
potentially microsecond resolution that marries well with Squeak's
64-bit integer support.  This approach worked very well for VisualWorks
where we got rid of lots of customer problems every 49.7 days (2^32
milliseconds).  There has been some concern expressed about the
performance impact of long integers but at least in VW that simply
wasn't an issue.

For general purpose apps, sure. Remember that my concern is what the effect of switching to largeint arithmetic is on our routers which time-stamp in and outgoing packets at several points so that we can keep track of latencies and where they're introduced. I will absolutely believe that in "average" use there's not going to be an impact, but I don't think that what we're doing (timestamping millions of times per second) can be exactly considered average here :-) You'll recall that the introduction of the jiffy clock was in response to the server spending some 20% or so in gettimeofday...

Hmmm.  Then, given that the clock's effective resolution is around 500Hz-1KHz, and that the 64-bit result is effectively immutable, there could be significant benefit in the primitive cacheing the current result, instantiating a new result object only when the time actually changes.

best
Eliot
 

Cheers,
 - Andreas


best
Eliot


   Thanks,
   Dave


   On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote:
    >
    > On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis
   <[hidden email] <mailto:[hidden email]>> wrote:
    >
    > >
    > > Eliot,
    > >
    > > Yes, it can be retracted. I may not get to it for a few days so
   feel
    > > free to do so on my behalf. I introduced the change in trunk to put
    > > some visibility on the new primitives, which appears to have
   achieved
    > > the intended purpose ;)
    > >
    > > With respect to the Squeak epoch, we do have an issue that needs to
    > > be clarified. In the Squeak implementation, we have the 1901 epoch,
    > > but AFAIK there is no specification of the time zone in which
   the epoch
    > > is defined. In the Squeak implementation, local time has
   consistently
    > > been used in the platform interface, and the actual values of the
    > > Squeak clock for any real point in time are different depending on
    > > the time zone in which the image happens to be running.
    > >
    >
    > It's implicit that it is GMT/UTC.  So the Squeak epoch is the
   start of 1901
    > in Greenwich.
    >
    > To put it another way, there is no such thing as "UTC & local
    > > microseconds from the Smalltalk epoch" unless there is a clearly
    > > defined transformation between the Smalltalk epoch and the posix
    > > epoch, and in practice (in Squeak at least) this is not the case.
    > > Midnight on January 1, 1901 in Palo Alto, California was a
   different
    > > point in time from midnight January 1, 1901 in London, and I cannot
    > > determine which of the two was the "real" Smalltalk epoch.
    > >
    >
    > The latter is the only one that makes good sense.
    >
    >
    > > This begs the question of why, in implementing the interface to
    > > the underlying platform, we would *not* want use the posix epoch
    > > as a reference point. The Posix epoch is well defined, well
   documented,
    > > well understood, and easily translated to any existing
   definition of
    > > the Smalltalk epoch. In contrast, the Smalltalk epoch is
   ambiguously
    > > defined, poorly documented, and widely misunderstood.
    > >
    >
    > I think its easy to fix; just define it to be the start of the
   20th century
    > in UTC.  That's what we did with VW and its easy to do with
   Squeak.  For me
    > backwards compatibility pushes strongly for keeping with the
   Squeak epoch,
    > i.e. Time seconds = Time milliseconds / 1000000.
    >
    > best,
    > Eliot
    >
    >
    > >
    > > Dave
    > >
    > > On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
    > > >
    > > > Hi David,
    > > >
    > > >     any chance of getting you to retract this?  The Cog VM
   has 64-bit UTC
    > > &
    > > > local microseconds from the Smalltalk epoch (1901), which are
   hence
    > > easier
    > > > to use as a basis for the Squeak clock and still last for ~
   54,000 years.
    > > >  I'd like to see the Cog and standard VMs converge on a
   primitive set.
    > >  This
    > > > is an issue for me since changing the epoch is, I think, an
   unnecessary
    > > > change.
    > > >
    > > > best
    > > > Eliot
    > > >
    > > > On Sat, Aug 14, 2010 at 4:55 PM, <[hidden email]
   <mailto:[hidden email]>> wrote:
    > > >
    > > > > Changes to Trunk (http://source.squeak.org/trunk.html) in
   the last 24
    > > > > hours:
    > > > >
    > > > >
    > > > >
    > >
   http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
    > > > >
    > > > > Name: Kernel-dtl.476
    > > > > Ancestors: Kernel-eem.475
    > > > >
    > > > > Add Time class>>primMicrosecondClock and Time
   class>>primUtcWithOffset
    > > for
    > > > > access to microsecond clock primitives available in newer
   Squeak VMs.
    > > > >
    > > > > primMicrosecondClock provides a system clock with nominal
   microsecond
    > > > > precision.
    > > > >
    > > > > primUtcWithOffset answers UTC time as microseconds since
   the Posix
    > > epoch
    > > > > and offset as seconds offset from GMT. The Squeak clock is
    > > traditionally
    > > > > implemented in terms of platform local time. Use of UTC
   time and offset
    > > is
    > > > > advantageous if time zones and daylight saving time offsets
   are to be
    > > > > considered.
    > > > >
    > > > > Example:
    > > > > { Time primMillisecondClock .
    > > > >   Time primMicrosecondClock .
    > > > >   Time primUtcWithOffset } ==> #(6932757 6932757830
   #(1281815075538304
    > > > > -14400))
    > > > >
    > > > >
    > > > > =============================================
    > > > >
    > > > >
    > >
    > >



Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

David T. Lewis
In reply to this post by Eliot Miranda-2
 
On Tue, Aug 24, 2010 at 09:43:54AM -0700, Eliot Miranda wrote:

> Hi David,
>
> On Tue, Aug 24, 2010 at 5:24 AM, David T. Lewis <[hidden email]> wrote:
>
> > Eliot,
> >
> > I am afraid that I may have misunderstood your original request
> > to retract the change.
> >
> > I assumed that you were refering to Time class>>primUtcWithOffset
> > that I had added to trunk (and I did remove that method), but
> > in rereading your note I think you may have been referring to
> > the earlier VMMaker updates that introduced the primitives
> > #primitiveMicrosecondClock and #primitiveUtcWithOffset. In
> > particular, #primitiveMicrosecondClock seems similar to the
> > Cog primitives, which include #primitiveUTCMicrosecondClock
> > and #primitiveLocalMicrosecondClock.
> >
> > Apologies for my misunderstanding, but can you please clarify
> > which methods you were suggesting should be retracted?
> >
> >        Interpreter>>primitiveMicrosecondClock
> >        Interpreter>>primitiveUtcWithOffset
> >        Time class>>primMicrosecondClock
> >        Time class>>primUtcWithOffset
> >
>
> If primitiveMicrosecondClock answers 64-bit UTC microseconds since 1901 this
> is the same as Cog's primitiveUTCMicrosecondClock and should be retained.

primitiveMicrosecondClock is like primitiveMillisecondClock in that
it answers a value that rolls over periodically, and it not a measure
of duration relative to any epoch. The extra precision is of course
meaningless for any individual call, but apparently is of value when
taken cumulatively for purposes of profiling. I will have to defer
to John as to whether it can or should be replaced by
primitiveUTCMicrosecondClock.

In any case, the meanings of primitiveMicrosecondClock and
primitiveUTCMicrosecondClock are different, and I should think
that they could safely coexist as long as we give them detailed
method comments to explain the time basis for each.

As long as you have no objection, I strongly prefer to retain
primitiveUtcWithOffset in its current form, regardless of whether
it actually gets used for anything near term. It's something that
Lex Spoon proposed ten years ago and it's near and dear to my heart
after my experience implementing the TimeZoneDatabase.

I note that I should change the primitive name in SqueakVM from
"primitiveUtcWithOffset" to "primitiveUTCWithOffset" for consistency.

>  It also needs a 64-bit local microseconds since 1901 which would be the
> same as Cog's primitiveLocalMicrosecondClock and a
> primitiveSignalAtUTCMicroseconds which is for 64-bit microseconds since 1901
> what primitiveSignalAtMilliseconds is for 30-bit wrapping milliseconds
> (again see Cog).

OK. And I would see no reason not to add these to the traditional SqueakVM
as well. If you have specific suggestions as to which of the new Cog
primitives should go into SqueakVM for consistency, that would help.
I am assuming that at some point we want the Squeak trunk to start making
use of the new Cog primitives, and that therefore they should also made
available in the traditional SqueakVM.

> We then need to agree on some primitive numbers or
> primitive names.  In Cog these three are
>
> (240 primitiveUTCMicrosecondClock) "was serial port primitive"
> (241 primitiveLocalMicrosecondClock) "was serial port primitive"
> (242 primitiveSignalAtUTCMicroseconds)
>
> Cog also has
> (243 primitiveUpdateTimezone) "primStringtranslatefromtotable"
>
> primitiveUpdateTimezone
> "Update the VMs notion of the current timezone.  The VM sets its notion
>  of the timezone once at start-up.  If one wants the VM to keep its notion
>  up-to-date arrange to invoke this primitive periodically."
> self ioUpdateVMTimezone
>
> which causes the VM to reevaluate the delta between UTC and local
> microseconds.
>
> With these four one has a non-wrapping synchronised timebase with
> potentially microsecond resolution that marries well with Squeak's 64-bit
> integer support.  This approach worked very well for VisualWorks where we
> got rid of lots of customer problems every 49.7 days (2^32 milliseconds).
>  There has been some concern expressed about the performance impact of long
> integers but at least in VW that simply wasn't an issue.
>

At this point, primitiveMicrosecondClock and primitiveUtcWithOffset
are not numbered primitives, and I see no need for them to be numbered.
As far as I know, no one else has plans to consume additional primitive
numbers, so we are following your lead with respect to assigning
primitive numbers (and I should update the SqueakVM table accordingly).

Thanks,
Dave

Reply | Threaded
Open this post in threaded view
|

Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

johnmci


On 2010-08-24, at 11:07 AM, David T. Lewis wrote:

> primitiveMicrosecondClock is like primitiveMillisecondClock in that
> it answers a value that rolls over periodically, and it not a measure
> of duration relative to any epoch. The extra precision is of course
> meaningless for any individual call, but apparently is of value when
> taken cumulatively for purposes of profiling. I will have to defer
> to John as to whether it can or should be replaced by
> primitiveUTCMicrosecondClock.

Well from the historical viewpoint the primitiveMillisecondClock would answer a value where zero was either the
boot time of the machine, the startup time of the app, or some epoch...  In listening to clients over the year's I
think they want it tied to the "standard" epoch because they do stuff like oh get the date & time, then oh um, grab the
millisecond clock and tack that onto the SECONDS. That ill defined behaviour isn't quite truthful if the two time values
are using different h/w clocks.

I note the reason behind the different zero times was because different hardware solutions were used over the years to
avoid the usually more expensive time/date calculation. But the thrust from the OS vendors has been to move away from
accessing the hardware directly so you end up with gettimeofday() anyway..


>   This approach worked very well for VisualWorks where we
>> got rid of lots of customer problems every 49.7 days (2^32 milliseconds).
>> There has been some concern expressed about the performance impact of l


Ya, I *was* the customer for that particular problem, and I thought it as 24.8 days being a signed integer (somewhere)...
Nothing like the client's mission critical world-wide choke point server crashing after X days...  
I'll not mention how many years the fix took.

The workaround was to assign some IT person to restart the app
every Monday morning at 6:00am so it was part of their weekly task list.



===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================