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

David T. Lewis lewis at mail.msen.com
Sat Aug 28 20:18:33 UTC 2010


Hi Andreas,

I just noticed something that looks odd in your original post on
this topic.  You referred to log files with time values like
"2010-08-18T23:17:49.888000007+00:00",
which is indeed silly nonsense. I am looking at a Squeak trunk
image on the traditional SqueakVM on Linux, and I never get values
like this for DateAndTime now. The nanos instance variable in
DateAndTime is coming from primitiveMillisecondClock which answers
an integer number of whole milliseconds, so I might get a DateAndTime
that looks like "2010-08-18T23:17:49.888+00:00". In other words,
the nanos might have a value like 888000000 but never 888000007.

I can't account for those 7 nanoseconds in your example, but
they certainly should not be coming from the millisecond clock.

Dave

On Sat, Aug 28, 2010 at 12:55:12PM -0400, David T. Lewis wrote:
> 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