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

Bert Freudenberg bert at freudenbergs.de
Mon Aug 23 09:40:38 UTC 2010


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 at 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))
>>> 
>>> 
>>> =============================================



More information about the Vm-dev mailing list