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, commits@source.squeak.org 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))
=============================================
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, commits@source.squeak.org 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))
=============================================
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, commits@source.squeak.org 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))
=============================================
On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis lewis@mail.msen.com 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, commits@source.squeak.org 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))
=============================================
2010/8/23 Eliot Miranda eliot.miranda@gmail.com:
On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis lewis@mail.msen.com 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, commits@source.squeak.org 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))
=============================================
On Mon, Aug 23, 2010 at 11:32 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2010/8/23 Eliot Miranda eliot.miranda@gmail.com:
On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis lewis@mail.msen.com
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-bitUTC &
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, commits@source.squeak.org 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))
=============================================
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 lewis@mail.msen.com 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, commits@source.squeak.org 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))
=============================================
Hi David,
On Tue, Aug 24, 2010 at 5:24 AM, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com
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-bitUTC
&
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, commits@source.squeak.org 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))
=============================================
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 <lewis@mail.msen.com <mailto:lewis@mail.msen.com>> 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, <commits@source.squeak.org <mailto:commits@source.squeak.org>> 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)) > > > > > > > > > > > > ============================================= > > > > > > > > > > > >
On Tue, Aug 24, 2010 at 10:18 AM, Andreas Raab andreas.raab@gmx.de 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 <lewis@mail.msen.com mailto:lewis@mail.msen.com> 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, <commits@source.squeak.org mailto:commits@source.squeak.org> 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)) > > > > > > > > > > > > ============================================= > > > > > > > > > > > >
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 lewis@mail.msen.com 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>>primUtcWithOffsetIf 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
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 johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Eliot Miranda -
John M McIntosh -
Nicolas Cellier