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

Andreas Raab andreas.raab at gmx.de
Sun Aug 29 01:50:19 UTC 2010


On 8/28/2010 1:18 PM, David T. Lewis wrote:
> 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.

There is specific code that does it if you ask for the #now at the same 
milliseconds:

(0 to: 9) collect:[:i| DateAndTime now].

You referred to http://bugs.squeak.org/view.php?id=474 and it states 
explicitly:

"[the code] preserves the logic so that

     (DateAndTime now) <= (DateAndTime now) is always false.

"

Cheers,
   - Andreas

>
> 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