[squeak-dev] Re: Date[And]Time fractional seconds printing

David T. Lewis lewis at mail.msen.com
Sat Aug 28 16:55:12 UTC 2010


On Sun, Aug 22, 2010 at 01:15:13PM -0700, Andreas Raab wrote:
> Hi -
> 
> I've been noodling on the issue of fractional seconds in Date[And]Time a 
> little more and after thinking through some of the implications it's 
> pretty clear to me that contrary to what I've been saying the root issue 
> probably isn't printing, but rather that Date[And]Time class>>now was 
> changed to include milliseconds.
> 
> The reason being that the fractional printing is an accurate 
> representation of the underlying value and I don't think that it'd be 
> good if two time values print the same but compare differently. This 
> should only ever happen in numerical edge cases but Time is specifically 
> designed to represent values accurately and so the 'lossy' printing 
> doesn't seem like the right response. Basically, it violates the 
> invariant of "(Time readFrom: aTime asString) = aTime".
> 
> Instead, I'm in favor to change Time class>>now (back) to *ignore* the 
> millisecond clock so that it uses seconds accuracy. For situations where 
> the millisecond clock should be taken into account I'd rather add a new 
> selector, for example #msecsNow that includes millisecond (or higher) 
> accuracy.
> 
> This way we can be explicit about when we use the historical behavior 
> and when not. Any thoughts?
> 
> Cheers,
>   - Andreas

I don't like the idea of having #now disregard fractional seconds.
Effectively that means that a request for the current time gets
automatically rounded or truncated to the nearest second, which is
just plain wrong. See http://bugs.squeak.org/view.php?id=474 for
background on making #now use fractional seconds (apparently Avi
did the original changes and Brent incorporated them into Squeak
Chronology).

I also note that the method comment for #printOn: indicates that
printing fractional seconds is in compliance with ISO 8601 and is
therefore the intended behavior (note that some of these methods
have my initials, but Brent is the real author).

http://www.w3.org/TR/NOTE-datetime

So it appears that there is nothing wrong with the current implemention
at all, aside from the fact that in many usages (such as writing a
time stamp in a log file) we don't want to see the fractional seconds.

Adding a new selector like #msecsNow as suggested above would certainly
work, but it seems to me that the word "now" has a very clear meaning,
and a method called #now should try to do exactly what it says.

There are a couple of other ways that we could address this issue:

1) Implement #rounded or #truncated on DateAndTime to answer an
   instance rounded or truncated to the nearest whole second.

2) Provide a variation on #printOn: that uses a format without
   fractional seconds. This would also be ISO 8601 compliant. The
   resulting string would useful for display purposes but could not
   be used to create a new instance of DateAndTime equal to the original. 

Dave

> On 8/19/2010 12:34 AM, 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
> >>
> >>
> >>
> >
> >
> >
> 



More information about the Squeak-dev mailing list