Problems with Time and AbtTimestamp

VA Smalltalk is a "100% VisualAge compatible" IDE that includes the original VisualAge technology and the popular VA Assist and WidgetKit add-ons.

Moderators: Eric Clayberg, wembley, tc, Diane Engles, solveig

Problems with Time and AbtTimestamp

Postby jtuchel » Thu Mar 27, 2008 5:23 am

Hi there,

I have some nice effects due to the fact that Time and AbtTimestamp perform strange roundings on their values of seconds. This is especially interesting when sending Time and AbtTimestamp instances over TCP/IP or persisting them in a file. What am I talking about:

Loot at Time>>#asSeconds
"Answer an Integer that is the number of
seconds since midnight of the receiver."

^millisecondsFromMidnight + 500 // 1000

Well, to my understanding, this method will answer a wrong number of seconds every time a second is in its second half. And that's exactly what's happening: if we persist the following (the method nextPut and getNext are just examples, but you get the idea):

aStream nextPut: myOriginalTime asSeconds

and later we create a Time instance by using:

myCopyTime := Time fromSeconds: aStream getNext

the following test will "randomly" be true or false, because the times differ by 1 second:

myCopyTime = my OriginalTime

I know I could use milliseconds, but not every imlementation of Time (look at VisualWorks, for example) will accept milliseconds. And for those, a wrongly rounded number of seconds is definitely wrong...
My expectation fro asSeconds would be that asSeconds returns me the number of fully passed seconds since midnight and not a random number between (number of fully passed seconds) and (number of fully passed seconds plus one)

The problem exists for timestamps as well, and there it is more of a problem, because we often use Timestamps for taking very exact times or for uniqueness of IDs...

Why does #asSeconds add 500 msecs before cutting off the microseconds???
Any thoughts?

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: Problems with Time and AbtTimestamp

Postby Eric Clayberg » Thu Mar 27, 2008 6:20 am

Isn't #asSeconds simply rounding to the nearest second? Adding half a second (500 milliseconds) and then truncating would seem to do just that. It certainly isn't "random".

It also makes sense that if you compare the rounded value to the original value it will typically not be the same (a 1 in 1000 chance).

It sounds like you need a new method named #asSecondsTruncated.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Re: Problems with Time and AbtTimestamp

Postby nmongeau » Thu Mar 27, 2008 6:48 am

Actually, I think your problem is not where you think it is.

Since Time>>#asSeconds trims off the milliseconds, and Time class>>#fromSeconds: converts seconds to milliseconds, an instance created with #fromSeconds: by its very nature has a trimmed down milliseconds value (rounded to the second). And since Time>>#= uses milliseconds as its comparison basis, this can never work (except when creating an instance of Time at exact second boundaries):

| t s t2 |
t := Time now.
s := t asSeconds.
t2 := Time fromSeconds: s.
t = t2

thus (almost) always returns false.

Normand
nmongeau
[|]
 
Posts: 29
Joined: Fri Jan 12, 2007 9:37 am

Re: Problems with Time and AbtTimestamp

Postby jtuchel » Thu Mar 27, 2008 7:00 am

Eric,

[quote="Eric Clayberg"]Isn't #asSeconds simply rounding to the nearest second? Adding half a second (500 milliseconds) and then truncating would seem to do just that. It certainly isn't "random".
[/quote]

Well, it is to some extent far from reality, at least in my definition: a rounded number of seconds since midnight can be in the future if we are in the second half of a second. If we care about seconds, it's not "random", but it's close to ;-)

But Normand surely is right: the problem is that #fromSeconds: will make this "error" visible.

Maybe I am just missing the point of rounding the seconds as compared to truncating. In our concrete scenario we had timestamps differ by exactly 1 second and this started quite some machinery of exception handling due to the difference. (If a value in the DB was concurrently changed in the future, some pieces of code might get confused, if only because of a single tiny second ... ;-) ).

If we had to handle the values only in VAST, there might be no problem, we could simply go on and use millis or micros, but some Time classes in other languages only hav a precision of a second...

cu

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: Problems with Time and AbtTimestamp

Postby Eric Clayberg » Thu Mar 27, 2008 8:46 am

nmongeau wrote:Actually, I think your problem is not where you think it is.

Since Time>>#asSeconds trims off the milliseconds, and Time class>>#fromSeconds: converts seconds to milliseconds, an instance created with #fromSeconds: by its very nature has a trimmed down milliseconds value (rounded to the second). And since Time>>#= uses milliseconds as its comparison basis, this can never work (except when creating an instance of Time at exact second boundaries):

| t s t2 |
t := Time now.
s := t asSeconds.
t2 := Time fromSeconds: s.
t = t2

thus (almost) always returns false.

Yes, exactly. Whether #asSeconds rounded or truncated, that comparison woud stil fail 999 times out of a 1,000.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Re: Problems with Time and AbtTimestamp

Postby nmongeau » Thu Mar 27, 2008 9:25 am

Joachim,

if I understand your position correctly, I believe that implementing a special constructor for your needs would solve your problem:

Time class>>nowCustom

^self fromSeconds: self now asSeconds

This would always give you instances of Time where the internal milliseconds value is rounded off to the nearest second.

Normand
nmongeau
[|]
 
Posts: 29
Joined: Fri Jan 12, 2007 9:37 am

Re: Problems with Time and AbtTimestamp

Postby jtuchel » Thu Mar 27, 2008 9:01 pm

Normand, Eric,

I think the problem here is two-fold.
First, there is the question if I can recreate an equal Time instance from some number of seconds that I got from another Time instance. As long as the transported amount of units (in this case seconds as opposed to milliseconds or microseconds), neither rounding nor truncating will help will help with my specific problem. We need to handle the problem differently, and we need to have a look at ways for our other systems reading the persisted Time objects to respect the higher precison of VAST.

The second aspect here is that I believe rounding is wrong. If it's 4:32:15.562 am, I would never expect to the result of #asSeconds to return 4:32:16.000 am, but rather 4:32:15.000 am, because that is the number of passed and measured Time units (seconds in that case). Or would you say that 5:32 pm is "around 6:00 pm" ?

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: Problems with Time and AbtTimestamp

Postby Eric Clayberg » Fri Mar 28, 2008 5:07 am

jtuchel wrote:First, there is the question if I can recreate an equal Time instance from some number of seconds that I got from another Time instance.

In general, this is not possible unless all of the time values have been rounded or truncated to some whole number of seconds.

jtuchel wrote:The second aspect here is that I believe rounding is wrong. If it's 4:32:15.562 am, I would never expect to the result of #asSeconds to return 4:32:16.000 am, but rather 4:32:15.000 am

I'm not sure why you would expect that. This is a simple issue of representing a fractional (more prcise) number as a whole (less precise) number. Just as in mathematics, rounding is perfectly appropriate. If you were to take 4:32:15.562 am and successively reduce its precision, you would get 4:32:15.56 am (rounded down), 4:32:15.6 am (rounded up) and finally 4:32:16 am (rounded up).

jtuchel wrote:because that is the number of passed and measured Time units (seconds in that case). Or would you say that 5:32 pm is "around 6:00 pm" ?

That would depend on the precision expected. I would typically round to the quarter hour when speaking of hours like that, so 5:32pm would be "around 5:30pm". Likewise, 5:43pm woudl be around 5:45pm and 5:56pm would be around 6:00pm. I woud round up or down depending on which quarter hour is closest. I would do the same thing if I were quoting the time to the nearest 5 minutes as well...5:32pm would become 5:30pm and 5:34pm would become 5:35pm.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Re: Problems with Time and AbtTimestamp

Postby jtuchel » Fri Mar 28, 2008 5:41 am

Eric,

You are perfectly right - in a mathematical sense. My (maybe personal) definition of a Time object would be the number of measured units that have passed since midnight. Rounding (up) is not appropriate under this definition, because the second the system has rounded up to hasn't fully passed yet. If I ask such an object for its hours, minutes or seconds, I think the answer should always be truncated.

This, however, doesn't change the hard truth: I cannot expect a copy of a Time object to be equal to its original if I reduce the precision at copy time. That is / was definitely our fault and we're on our own for a solution, independent of the rounding/truncation question.

Wherever this thread may lead to, I thank you and Norman for pointing me to the obvious: never expect a reduced precision copy to be equal to its original.

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: Problems with Time and AbtTimestamp

Postby Eric Clayberg » Fri Mar 28, 2008 5:50 am

jtuchel wrote:I ask such an object for its hours, minutes or seconds, I think the answer should always be truncated.

Have you tried the existing #hours, #minutes, or #seconds methods? ;-) The #seconds method is distinct from the #asSeconds method.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Re: Problems with Time and AbtTimestamp

Postby jtuchel » Fri Mar 28, 2008 6:02 am

Eric,

we didn't use them because the code we ported from VW already used asSeconds, and this method already returns the absolute number of seconds. It's no rocket science to implement a special myAsSeconds which does the math of converting #hours and #minutes to seconds, or (sic) do the same as asSeconds but without rounding :D

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany


Return to VA Smalltalk 7.0, 7.5 & 8.0

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest