On Fri, Mar 25, 2016 at 12:48:17AM +0800, Ben Coman wrote:
> On Thu, Mar 24, 2016 at 7:12 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > I'm actually quite happy with the idea of the value being a Number that
> > is an Integer for all reasonable values that could ever be supplied by
> > the VM, but that might be a Fraction if we want to represent time values
> > at some higher precision. Mainly I like it because it seems good conceptually
> > to think of time as continuous, and not as discreet ticks of a clock.
> >
> > It also works well computationally, because the normal case uses integer
> > values (immediates in 64-bit Spur), and because Fractions involve two
> > integer values, which presumably would be no worse than a design that
> > added another field. But given that none of our computers or VMs can
> > report time to a precision greater than microseconds, I think that we
> > can safely ignore the issue for another 20 years or so ;-)
> 
> Its not so far away. Three contemporary examples...
> 
> * Systems that synchronise time from GPS do so "typically well within
> 40 nanoseconds" [1]
> 
> * The distributed clock of EtherCAT networks synchronises nodes to
> better than 100ns. See slide 23 [2] and figure 7 [3].
> 
> * IEEE 1588 provides synchronised network time "in the range of
> +/-200ns between some nodes and even +/-50ns and less between the
> better ones." [4]
> 
> This matters for applications like financial trading, motion control
> and sequence-of-event logging on industrial plants.  Maybe not
> Smalltalk's bread and butter, but the last two are areas I'd like to
> use it at a co-ordinator level.
> 
> cheers -ben
> 
> [1] http://gpsinformation.net/main/gpstime.htm
> [2] https://ece.uwaterloo.ca/~sfischme/rate/Joey-Stubbs-Ethercat.pdf
> [3] http://www.iestcfa.org/bestpaper/wfcs10/wfcs10_bpa.pdf
> [4] https://home.zhaw.ch/~wei/IEEE1588/embedded_World_05_Contribution_final.pdf

Indeed you are quite right. And thank you for those links.

Our current Squeak platforms are certainly not real time systems, but
our representation of DateAndTime should not be limited by that.

I guess that all I can add at this point is my basic premise that a
simple representation of a time scale is better than a complicated
one. For now, the idea of microseconds as the unit of measure seems
to work quite well. Maybe in the future some different representation
will be better.

At higher levels of precision, I suspect that Fraction (or ScaledDecimal,
which is more readable) will be a very efficient representation. And since
DateAndTime instances are likely to be important for databases, forcing
all of the values to be Fraction (i.e. two integers) might be a good
policy. But for now, microseconds since the epoch works well, yielding
Integer representations in all practical cases, and overflowing into
Fraction if nanosecond precision is needed.

Dave