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

David T. Lewis lewis at mail.msen.com
Tue Aug 24 12:24:16 UTC 2010


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