[squeak-dev] Time primitives

David T. Lewis lewis at mail.msen.com
Wed Apr 8 01:10:38 UTC 2015


On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote:
> On Tue, 7 Apr 2015, David T. Lewis wrote:
> 
> >I am away and cannot double check the code right now, but the primitives
> >should be consistent across Cog and the interpreter VM. There had been
> >some confusion due to the early fork between trunk and oscog, but I
> >believe that Eliot and I got it sorted out quite a while ago.
> 
> I can confirm this, but the primitives don't work correctly on the 
> Interpreter VM (4.10.2.2614 on linux from squeakvm.org):
> 
> Time primUTCMicrosecondClock. "==> 2177453298247316"
> Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)"
> DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00"
> 
> The same with CogVM:
> 
> Time primUTCMicrosecondClock. "==> 3605895086935548"
> Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)"
> DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00"
> 

Why do you think this is wrong? I suspect that the one hour time zone
offset in your image is not in agreement with the three hour offset that
your operating system is reporting. The difference in absolute microseconds
is due to different origins in the time scale. Eliot's primitive used the
Smalltalk epoch UTC as its origin, and mine used Posix. Neither is wrong.

> >
> >These are not necessarily set up as numbered primitives, but the
> >implementations are there, and they can be called as named primitives in
> >Cog/Spur and interpreter VMs.
> >
> >I don't know about the Pharo fork, it's quite possible that things have
> >gotten renamed there.
> 
> The primitives are the same, but the method names in the image are not, 
> and the latter is what matters for me. It's a pain to keep code running in 
> both branches.
> 
> >
> >Note, the UTC with offset primitive is important to me because of
> >UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed
> >around the notion of a single primitive answering UTC time and local
> >offset as an atomic call to the VM.
> 
> It seems like this primitive caches the time zone offset, which is bad 
> when there are daylight savings changes (or when the machine goes to a 
> different time zone). Here's the current value from a long running image:
> 
> Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)"
> 
> But the LocalePlugin's primitives seem like they know the truth:
> 
> Locale current primTimezone. "==> 120"
> Locale current primDST. "==> true"
>

If you are suggesting that the handling of time zones in the various images
is less than perfect, then I will be the first to agree with you. But I don't
think that the primitives are wrong.

We have this primitive:

  InterpreterPrimitives>>primitiveUtcWithOffset
	"Answer an array with UTC microseconds since the Posix epoch and
	the current seconds offset from GMT in the local time zone. An empty
	two element array may be supplied as a parameter.
	This is a named (not numbered) primitive in the null module (ie the VM)"

And the unix platforms sources implement it like this (with ifdefs removed
for clarity):

  sqInt sqUnixUtcWithOffset(sqLong *microSeconds, int *offset)
  {
    struct timeval timeval;
    if (gettimeofday(&timeval, NULL) == -1) return -1;
    time_t seconds= timeval.tv_sec;
    suseconds_t usec= timeval.tv_usec;
    *microSeconds= seconds * 1000000 + usec;
    *offset= localtime(&seconds)->tm_gmtoff;
    return 0;
  }

So the operating system is telling you its best estimate of the current time
in microseconds since the Posix epoch, as well as the local time zone offset
in seconds at the time of the call. This is a single gettimeofday() call to
the platform runtime library, which is about as close as we can get to a
coherent result on general purpose unix systems.

Dave



More information about the Squeak-dev mailing list