Time properties declared INTEGER return fractional seconds, and overflow beyond 68 years

[AlexKirkouski]

Description

The time properties of the Time module are declared INTEGER, but the value they return is not whole:

CLASS WorkCenter;
shiftFrom = DATA DATETIME (WorkCenter);
shiftTo = DATA DATETIME (WorkCenter);

capacitySeconds (WorkCenter w) = subtractSeconds(shiftTo(w), shiftFrom(w));   // declared INTEGER
capacityMinutes (WorkCenter w) = capacitySeconds(w) / 60;                     // whole division, by the declared classes

With shiftFrom = 00:00:00.500 and shiftTo = 00:01:00, capacitySeconds is 59.5, not 59 or 60. Nothing shows that until the value is stored or read, and there it is rounded, so the property reports 60. capacityMinutes is computed as a fraction as well - 0.99 instead of the 0 that a whole division of two INTEGER values gives.

The same applies to secondsBetweenDates, toSeconds and getMilliSeconds, and, without the fractional part, to extractWeek and extractDOWNumber, whose neighbours (extractHour, extractYear, ...) do bring the result back to INTEGER.

Besides being wrong, seconds between two dates do not fit in INTEGER beyond about 68 years.

Reason

Those properties are defined through the epoch of a time interval, which the database returns as a fractional number, and the platform trusts the declared class instead of bringing the expression to it, so both the fractional part and the wider database type reach every expression built on top.

They return whole seconds now, truncated towards zero, and are declared LONG; extractWeek and extractDOWNumber are brought back to INTEGER. The behaviour an upgrading application can notice is described in the migration notes.