[Vm-dev] 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
>     <lewis at mail.msen.com <mailto: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
>     <mailto: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))
>      > > > >
>      > > > >
>      > > > > =============================================
>      > > > >
>      > > > >
>      > >
>      > >
>
>