I don't know the reason for carrying nanoseconds. With respect to
complexity, the nanosecond implementation is no more complex than
would be the case for microseconds, and I don't think it has any
additional computational penalty, so my guess would be that nanoseconds
were chosen in order to provide essentially unlimited precision.

To my mind, the more worthwhile simplification would be to represent
time as a magnitude (one number, rather than jdn, seconds, nanos and
offset). In other words, keep the protocol for DateAndTime the
same but let the underlying representation be a Number of seconds
UTC since the epoch. This would simplify time arithmetic (think
calculation of duration across a daylight savings time transition),
and I suspect that it might help performance, given the heavy use
of time stamps in source files, Monticello, etc. But it would
be a lot of work to implement this, and I have never gotten around
to trying it.

Dave

On Thu, Aug 19, 2010 at 12:34:19AM -0700, Andreas Raab wrote:
> Hi David -
> 
> Thanks for the info. Out of curiosity, why are we carrying those nanos 
> around to begin with? Who uses them where and for what purpose? It seems 
> to me that there's a whole lot of complexity that I see absolutely no 
> reason for.
> 
> Cheers,
>   - Andreas
> 
> On 8/18/2010 9:43 PM, David T. Lewis wrote:
> >On Wed, Aug 18, 2010 at 04:30:02PM -0700, Andreas Raab wrote:
> >>Hi -
> >>
> >>I've noticed a while ago that at some point in the evolution of Squeak
> >>both Time as well as DateAndTime had "nano seconds" added.
> >>Unfortunately, the default printing of both of these classes leads to
> >>some extremely strange effects now. For example, where historically
> >>something like
> >>
> >>	DateAndTime now asUTC.
> >>
> >>would print "2010-08-18T23:23:54+00:00" it now prints silly nonsense
> >>like this: "2010-08-18T23:17:49.888000007+00:00" (I just found this in
> >>one of our log files). Similarly, if you evaluate "Time now" you get
> >>results like "4:22:07.369 pm".
> >>
> >>In short, the question is: Is there any point whatsoever to print
> >>fractional seconds by default? It seems to me that if you need to print
> >>fractional seconds you might as well use some other selector and leave
> >>#printOn: with the historical behavior of not printing fractional seconds.
> >
> >Ick. There is no justification for printing fractional seconds in this
> >context, because we expect the #printString to resemble a standard date
> >string.
> >
> >Regrettably, the offending method DateAndTime>>printOn:withLeadingSpace:
> >is stamped with my initials from 10/31/2004 in this change set:
> >
> >   Change Set:   DateAndTimePrintOnFix-dtl
> >   Date:         5 November 2004
> >   Author:       David T. Lewis
> >
> >   The #printOn: for DateAndTime did not insert a decimal point for the
> >   fractional part of seconds (nanoseconds). This change set provides a 
> >   fix.
> >
> >But I think that this was a cosmetic fix to a method that entered the
> >image some time after Squeak 3.6.
> >
> >Until recently, "DateAndTime now" answered an object with no nanoseconds,
> >so the fractional seconds printing feature was not visible. At some point
> >in recent Squeak history, "DateAndTime now" began producing instances
> >with non-zero nonos fields. This is a good thing, but it has the side
> >effect of triggering the fractional seconds printing (mis)feature in
> >DateAndTime>>printOn:withLeadingSpace: which is not a good thing.
> >
> >Note, if you open a Squeak 3.8 image, inspect "DateAndTime now", then
> >set the nanos instance variable to some non-zero value, you will see
> >the same questionable #printString behavior.
> >
> >>Anyone in favor of preserving fractional seconds by default please raise
> >>your hand and provide some arguments why such behavior would be 
> >>preferable.
> >
> >No. It is nice to display the fractional seconds, but not by default in
> >the #printOn: method. A different selector might be a acceptable, perhaps
> >something like #printOn:withLeadingSpaces:withFractionalSeconds:
> >
> ><OT>
> >IMHO, the meta-issue is that time should be represented as a simple
> >magnitude rather than as a mashup of discreet whole numbers (the instance
> >variables in DateAndTime) passing through various transformations to
> >represent durations or to display time and date strings.
> ></OT>
> >
> >Dave
> >
> >
> >
>