Is Time>>asSeconds correct?

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

Hi Joachim,

We'll have to do some software archeology on this one.
I do see a forum post here on the matter and we'll just have to work our way backwards to the change in 8.0.3
https://groups.google.com/u/1/g/va-smalltalk/c/wgnMcOSOtrA/m/wH_SVMrxpSAJ

- Seth

On Monday, February 8, 2021 at 1:39:20 PM UTC-5 [hidden email] wrote:

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

The timestamp on the method is 2001.
So I think this puts it in IBM Visualage timeframe, so it will be unlikely I can find the change request associated with this.

However, we'll take a look.

- Seth

On Monday, February 8, 2021 at 2:40:59 PM UTC-5 Seth Berman wrote:

Hi Joachim,

We'll have to do some software archeology on this one.
I do see a forum post here on the matter and we'll just have to work our way backwards to the change in 8.0.3
https://groups.google.com/u/1/g/va-smalltalk/c/wgnMcOSOtrA/m/wH_SVMrxpSAJ

- Seth

On Monday, February 8, 2021 at 1:39:20 PM UTC-5 [hidden email] wrote:

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

The timestamp on the method is 2001.
So I think this puts it in IBM Visualage timeframe, so it will be unlikely I can find the change request associated with this.

However, we'll take a look.

- Seth

On Monday, February 8, 2021 at 2:40:59 PM UTC-5 Seth Berman wrote:

Hi Joachim,

We'll have to do some software archeology on this one.
I do see a forum post here on the matter and we'll just have to work our way backwards to the change in 8.0.3
https://groups.google.com/u/1/g/va-smalltalk/c/wgnMcOSOtrA/m/wH_SVMrxpSAJ

- Seth

On Monday, February 8, 2021 at 1:39:20 PM UTC-5 [hidden email] wrote:

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

Thanks, Seth,

Thanks for looking into this.

Going thorugh Lou's thread from 2011, I guess we tend to all agree that rounding the seconds is at least a bit smelly. We are going to implement our own comparison extension method in AbtTimestamp that truncates the Time's seconds. This will at least restore the Application's behaviour.

Joachim

BTW: you mentioned Software archeology. Ain't it funny how Software evolves into more and more science fields? It once started as a craft of Software Development, these days we have archeology, architecture and whatnot involved. I even work as a Software Geriatrist from time to time, where there is a lot of anaesthetics involved (both for users, management and methods) ;-)

Seth Berman schrieb am Montag, 8. Februar 2021 um 20:47:02 UTC+1:

The timestamp on the method is 2001.
So I think this puts it in IBM Visualage timeframe, so it will be unlikely I can find the change request associated with this.

However, we'll take a look.

- Seth

On Monday, February 8, 2021 at 2:40:59 PM UTC-5 Seth Berman wrote:

Hi Joachim,

We'll have to do some software archeology on this one.
I do see a forum post here on the matter and we'll just have to work our way backwards to the change in 8.0.3
https://groups.google.com/u/1/g/va-smalltalk/c/wgnMcOSOtrA/m/wH_SVMrxpSAJ

- Seth

On Monday, February 8, 2021 at 1:39:20 PM UTC-5 [hidden email] wrote:

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

Hi Joachim

from my archiv:

VAST 5.0 and before (Windows NT 4.0)

Time>>asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

    ^secondsFromMidnight

vs

VAST 6.04 (last IBM Version, Windows 2000 and later)

Time>>asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."
    ^millisecondsFromMidnight + 500 // 1000

To look into VAST 5.5 to narrow down would require me to invest some more effort (to install it in an ancient Windows).

But for short, information from the migration guide 6.0 (out of the information center) tells me

Time class shape changed
In order to increase the precision of Time, an instance variable, milliseconds, has been added and the secondsSinceMidnight instance variable has been renamed to millisecondsSinceMidnight. This change should be transparent to existing applications since the API for Time was not changed, only extended.
The object loader mutation method for Time has been updated to account for the difference in class shape. This will make loading instances of Time that were dumped by a previous version of VisualAge Smalltalk work correctly as long as you did not specify the optimization of not including variable names when you created the dumped file (the default behavior is for variable names to be included).

So two things happened: obviously raising the clock granularity from seconds to milliseconds AND hidden here to treat time rolling back as mentioned in the migration guide elsewhere  under "Behavior change in handling negative system time" -> e.g. switch summer to winter time etc.

Without proof: when switching from seconds to milliseconds the rounding code supported a smooth transition of old code before 6.0 based on ticks per second. 

A look from today at this code, not knowing about that details, gives you a courious impression about that code fragment.

Marcus

[hidden email] schrieb am Dienstag, 9. Februar 2021 um 08:43:03 UTC+1:

Thanks, Seth,

Thanks for looking into this.

Going thorugh Lou's thread from 2011, I guess we tend to all agree that rounding the seconds is at least a bit smelly. We are going to implement our own comparison extension method in AbtTimestamp that truncates the Time's seconds. This will at least restore the Application's behaviour.

Joachim

BTW: you mentioned Software archeology. Ain't it funny how Software evolves into more and more science fields? It once started as a craft of Software Development, these days we have archeology, architecture and whatnot involved. I even work as a Software Geriatrist from time to time, where there is a lot of anaesthetics involved (both for users, management and methods) ;-)

Seth Berman schrieb am Montag, 8. Februar 2021 um 20:47:02 UTC+1:

The timestamp on the method is 2001.
So I think this puts it in IBM Visualage timeframe, so it will be unlikely I can find the change request associated with this.

However, we'll take a look.

- Seth

On Monday, February 8, 2021 at 2:40:59 PM UTC-5 Seth Berman wrote:

Hi Joachim,

We'll have to do some software archeology on this one.
I do see a forum post here on the matter and we'll just have to work our way backwards to the change in 8.0.3
https://groups.google.com/u/1/g/va-smalltalk/c/wgnMcOSOtrA/m/wH_SVMrxpSAJ

- Seth

On Monday, February 8, 2021 at 1:39:20 PM UTC-5 [hidden email] wrote:

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

Thanks, Seth,

Thanks for looking into this.

Going thorugh Lou's thread from 2011, I guess we tend to all agree that rounding the seconds is at least a bit smelly. We are going to implement our own comparison extension method in AbtTimestamp that truncates the Time's seconds. This will at least restore the Application's behaviour.

Joachim

BTW: you mentioned Software archeology. Ain't it funny how Software evolves into more and more science fields? It once started as a craft of Software Development, these days we have archeology, architecture and whatnot involved. I even work as a Software Geriatrist from time to time, where there is a lot of anaesthetics involved (both for users, management and methods) ;-)

Seth Berman schrieb am Montag, 8. Februar 2021 um 20:47:02 UTC+1:

The timestamp on the method is 2001.
So I think this puts it in IBM Visualage timeframe, so it will be unlikely I can find the change request associated with this.

However, we'll take a look.

- Seth

On Monday, February 8, 2021 at 2:40:59 PM UTC-5 Seth Berman wrote:

Hi Joachim,

We'll have to do some software archeology on this one.
I do see a forum post here on the matter and we'll just have to work our way backwards to the change in 8.0.3
https://groups.google.com/u/1/g/va-smalltalk/c/wgnMcOSOtrA/m/wH_SVMrxpSAJ

- Seth

On Monday, February 8, 2021 at 1:39:20 PM UTC-5 [hidden email] wrote:

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim

On Monday, February 8, 2021 at 11:43:03 PM UTC-8 [hidden email] wrote:

Thanks, Seth,

Thanks for looking into this.

Going thorugh Lou's thread from 2011, I guess we tend to all agree that rounding the seconds is at least a bit smelly. We are going to implement our own comparison extension method in AbtTimestamp that truncates the Time's seconds. This will at least restore the Application's behaviour.

Smelly? Stinkiest cheese ever! :-)

Your requirements, as you described them, were to detect two transactions within one second. So, 58.9 and 59.1 should say they are within one second, not two different seconds. Don't truncate, just take the difference and test that.

Joachim

BTW: you mentioned Software archeology. Ain't it funny how Software evolves into more and more science fields? It once started as a craft of Software Development, these days we have archeology, architecture and whatnot involved. I even work as a Software Geriatrist from time to time, where there is a lot of anaesthetics involved (both for users, management and methods) ;-)

Seth Berman schrieb am Montag, 8. Februar 2021 um 20:47:02 UTC+1:

The timestamp on the method is 2001.
So I think this puts it in IBM Visualage timeframe, so it will be unlikely I can find the change request associated with this.

However, we'll take a look.

- Seth

On Monday, February 8, 2021 at 2:40:59 PM UTC-5 Seth Berman wrote:

Hi Joachim,

We'll have to do some software archeology on this one.
I do see a forum post here on the matter and we'll just have to work our way backwards to the change in 8.0.3
https://groups.google.com/u/1/g/va-smalltalk/c/wgnMcOSOtrA/m/wH_SVMrxpSAJ

- Seth

On Monday, February 8, 2021 at 1:39:20 PM UTC-5 [hidden email] wrote:

always -> almost

Joachim Tuchel schrieb am Montag, 8. Februar 2021 um 19:37:36 UTC+1:

Hi there,

I just stumbled across some interesting thing that was embedded in a longer story in a customer project which migrates from VisualAge to VA Smalltalk. In order to decide whether an object can or must be updated in the database, they want to find out whether a Timestamp is in the same second as a newly created one. Thus updates shouldn't be possible more often than once a second.

The old implementation modified existing timestamps by setting the millieconds to zero. (well, it did something more complicated than that, but...).

So I suggested we just use totalSeconds of two timestamps to find out whether they represent the same second. And looking at totalSeconds in AbtTimestamp, that looks just rigt. It returns the Date's asSeconds plus the Time's asSeconds. So far so good.

But things went crazy. Two Timestamps that had been equal for years were not any more.

I dug down a little deeper and found this:

Time>>#asSeconds

    "Answer an Integer that is the number of
     seconds since midnight of the receiver."

  ^millisecondsFromMidnight + 500 // 1000

What....? The seconds are ROUNDED? So if we use #totalSeconds to compare two AbtTimestamps they are only equal if they are in the same half of a second?

I would say this is not only surprising, it even doesn't match well with the method's comment. And I'd go so far as to say it is wrong. I would assume that at 18:12:34.953 the number of seconds since midnight is the same number as at 18:12:34.000 and not one more, just because the second is always over.

Does this make sense at all? What is the idea behind this?

Joachim