Date[And]Time fractional seconds printing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Date[And]Time fractional seconds printing

Andreas.Raab
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.

Anyone in favor of preserving fractional seconds by default please raise
your hand and provide some arguments why such behavior would be preferable.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Casey Ransberger-2
I wondered what the deal was with that when I was playing with Date in the process of poking at the class comment.

On Wed, Aug 18, 2010 at 4:30 PM, Andreas Raab <[hidden email]> 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.

Anyone in favor of preserving fractional seconds by default please raise your hand and provide some arguments why such behavior would be preferable.

Cheers,
 - Andreas




--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

David T. Lewis
In reply to this post by Andreas.Raab
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


Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Andreas.Raab
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
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

David T. Lewis
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
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Colin Putney

On 2010-08-19, at 4:56 AM, David T. Lewis wrote:

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

I've done this. The MDTimestamp class in Monticello 2.x is a subclass of Magnitude. Internally it's organized as a 4-byte value representing the number of seconds since March 1, 1980. There's also a (slightly incomplete) MDTimestampPrinter class that prints timestamps using format strings similar to strftime(). The approach worked out quite well.

Colin
Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

David T. Lewis
On Thu, Aug 19, 2010 at 09:37:39AM -0700, Colin Putney wrote:

>
> On 2010-08-19, at 4:56 AM, David T. Lewis wrote:
>
> > 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.
>
> I've done this. The MDTimestamp class in Monticello 2.x is a subclass
> of Magnitude. Internally it's organized as a 4-byte value representing
> the number of seconds since March 1, 1980. There's also a (slightly
> incomplete) MDTimestampPrinter class that prints timestamps using
> format strings similar to strftime(). The approach worked out quite well.

Colin,

Good to know about this. What aspect of this worked well? Is this
done for performance or for other reasons?

Thanks,
Dave


Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Andreas.Raab
In reply to this post by Andreas.Raab
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

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


Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

David T. Lewis
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
> >>
> >>
> >>
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

David T. Lewis
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
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Andreas.Raab
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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Andreas.Raab
In reply to this post by David T. Lewis
Hi David -

On 8/28/2010 9:55 AM, David T. Lewis wrote:
> 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.

I see your point, but I disagree. To me this is a classic question of
"what should the default be?". And the default should be what most users
of #now expect. From the code that I've looked at, I still haven't found
any place that would benefit from fractional seconds. If that is true,
then I think the default should be whole seconds, with a protocol
allowing to ask for fractional seconds if that case ever comes up. If
you know of any examples in the current system that benefit from
fractional seconds in #now I'd really love to see them.

BTW, does anyone know what the result of "Date[And]Time now" is in other
systems? What do VW, GST, and others return? Whole seconds or fractional?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Eliot Miranda-2


On Sat, Aug 28, 2010 at 7:18 PM, Andreas Raab <[hidden email]> wrote:
Hi David -


On 8/28/2010 9:55 AM, David T. Lewis wrote:
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.

I see your point, but I disagree. To me this is a classic question of "what should the default be?". And the default should be what most users of #now expect. From the code that I've looked at, I still haven't found any place that would benefit from fractional seconds. If that is true, then I think the default should be whole seconds, with a protocol allowing to ask for fractional seconds if that case ever comes up. If you know of any examples in the current system that benefit from fractional seconds in #now I'd really love to see them.

BTW, does anyone know what the result of "Date[And]Time now" is in other systems? What do VW, GST, and others return? Whole seconds or fractional?

VisualWorks answers whole seconds (as did Smalltalk-80 v2):

| s t c |
c := 0.
t := Time now.
[(s := Time now) = t] whileTrue.
[(t := Time now) = s] whileTrue: [c := c + 1].
Array with: s with: t with: c #(8:37:52 PM 8:37:53 PM 79465)
 

Cheers,
 - Andreas




bpi
Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

bpi
In reply to this post by Andreas.Raab
Hi Andreas,

Am 29.08.2010 um 04:18 schrieb Andreas Raab:
> BTW, does anyone know what the result of "Date[And]Time now" is in other systems? What do VW, GST, and others return? Whole seconds or fractional?

On VA Smalltalk 8.0.2 I get the following when I print it:
DateAndTime now 2010-08-29T12:47:26.778+01:00

Cheers,
Bernhard
bpi
Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

bpi
For what it's worth, here the relevant extract from the ANSI Standard:

5.8.1.24 Message Refinement: printString
Synopsis
Return a string that describes the receiver.
Definition: <Object>
A string consisting of a sequence of characters that describe the receiver are returned as the result.
The exact sequence of characters that describe an object are implementation defined.
Refinement: <DateAndTime>
The returned string will represent the UTC time of the receiver offset from UTC by the offset of the receiver. All dates are in the astronomical Gregorian calendar. The result will be formatted as
-YYYY-MM-DDThh:mm:ss.s+ZZ:zz:z where - is the <Character> $- if the year is less than 0 otherwise it is the <Character> that is
returned from the message #space sent to the standard global Character,
YYYY is the year left zero filled to four places,
- is the <Character> $-,
MM is the month of the year left zero filled to two places,
- is the <Character> $-,
DD is the day of the month left zero filled to two places,
T is the <Character> $T,
hh is the hour in the 24-hour clock left zero filled to two places,
: is the <Character> $:,
mm is the minute left zero filled to two places,
: is the <Character> $:,
ss is the second left zero filled to two places,
. is the <Character> $. and is present only if the fraction of a second is non-zero,
s is the fraction of a second and is present only if non-zero,
+ is the <Character> $+ if the offset is greater than or equal to <Duration factory> #zero and the <Character> $- if it is less,
ZZ is the hours of the offset left zero filled to two places, and : is the <Character> $:, zz is the minutes of the offset left zero filled to two places, : is the <Character> $: and is present only if the seconds of the offset is non-zero,
z is the seconds of the offset including any fractional part and is present only if non- zero.
This format is based on ISO 8601 sections 5.3.3 and 5.4.1.
Example: 8:33:14.321 PM EST January 5, 1200 B.C.
'-1199-01-05T20:33:14.321-05:00'
Example: 12 midnight UTC January 1, 2001 A.D.
' 2001-01-01T00:00:00+00:00'
Return Values
<readableString> unspecified
Errors
none

Cheers,
Bernhard

Am 29.08.2010 um 12:49 schrieb Bernhard Pieber:

Hi Andreas,

Am 29.08.2010 um 04:18 schrieb Andreas Raab:
BTW, does anyone know what the result of "Date[And]Time now" is in other systems? What do VW, GST, and others return? Whole seconds or fractional?

On VA Smalltalk 8.0.2 I get the following when I print it:
DateAndTime now 2010-08-29T12:47:26.778+01:00

Cheers,
Bernhard



Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

David T. Lewis
In reply to this post by Andreas.Raab
On Sat, Aug 28, 2010 at 06:50:19PM -0700, Andreas Raab wrote:

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

D'oh! Of course.

Wow, you must be doing a *lot* of accesses to "DateAndTime now" in
order to get results like this. Something approaching a thousand per
second I should guess.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Andreas.Raab
In reply to this post by bpi
On 8/29/2010 3:49 AM, Bernhard Pieber wrote:
> Hi Andreas,
>
> Am 29.08.2010 um 04:18 schrieb Andreas Raab:
>> BTW, does anyone know what the result of "Date[And]Time now" is in other systems? What do VW, GST, and others return? Whole seconds or fractional?
>
> On VA Smalltalk 8.0.2 I get the following when I print it:
> DateAndTime now 2010-08-29T12:47:26.778+01:00

Thanks. Is there a method to retrieve the current time with seconds
accuracy, or round it to seconds or similar?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Andreas.Raab
In reply to this post by David T. Lewis
On 8/29/2010 6:24 AM, David T. Lewis wrote:

> On Sat, Aug 28, 2010 at 06:50:19PM -0700, Andreas Raab wrote:
>> 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.
>>
>> "
>
> D'oh! Of course.
>
> Wow, you must be doing a *lot* of accesses to "DateAndTime now" in
> order to get results like this. Something approaching a thousand per
> second I should guess.

Err, no. Only a few calls to #now within the same millisecond (the above
example doesn't call it thousands of times, it calls it nine times, but
within the same millisecond value). Given that the time resolution on
Linux systems is generally very poor, that is not difficult at all.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Bernhard Pieber
In reply to this post by Andreas.Raab
Hi Andreas,

Am 29.08.2010 um 19:26 schrieb Andreas Raab:
> Thanks. Is there a method to retrieve the current time with seconds accuracy, or round it to seconds or similar?
I checked but I don't see anything like this.

Cheers,
Bernhard

Reply | Threaded
Open this post in threaded view
|

Re: Date[And]Time fractional seconds printing

Hannes Hirzel
Hello all in this thread,

as you are working on the 'Kernel-Chronology' package. May I ask you
to provide some class comments for the Timespan class?

And the subclasses

Timespan subclasses  {Month . Schedule . Week . Year . Date}

Regards
Hannes

On 8/29/10, Bernhard Pieber <[hidden email]> wrote:

> Hi Andreas,
>
> Am 29.08.2010 um 19:26 schrieb Andreas Raab:
>> Thanks. Is there a method to retrieve the current time with seconds
>> accuracy, or round it to seconds or similar?
> I checked but I don't see anything like this.
>
> Cheers,
> Bernhard
>
>