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

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

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

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

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

On Sat, Aug 28, 2010 at 7:18 PM, Andreas Raab andreas.raab@gmx.de 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

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

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