FWD » Core Development » Base Language

There's a bug in FWD which is exposed when a DST boundary is reached:

def var d as datetime.
d = datetime("10-10-2019").
message string(d).
do while d < now:
d = add-interval(d, 15, "minutes").
end.
message string(d).

In FWD, the test above goes into an infinite loop because, as when reaching 10/27/2019 02:45:00.000 and adding 15 minutes, instead of going to 10/27/2019 03:00:00, it goes back to 2AM hour.

In short, the problem is this:

def var d as datetime.
d = datetime("10-27-2019 02:59:59").
message string(d).
d = add-interval(d, 1, "seconds").
message string(d). // instead of 3AM, this goes back to 3AM

Also, this poses some other questions: does 4GL ever keep track of the DST hour, when doing operations with the DST day? For example, the 10-27-2019 day had 25 hours in reality, not 24. And this also may be dependent on the timezone, so some datetime-tz tests would be needed.

This behaviour is somewhat expected. The problem is that we use "convention" time units instead of "physical" axis. Our daily time conventions are quite complicated and differ from country to country and reference time (Note: from next year some the UE countries will drop DST, which will add to this complexity). See below a sample graphic for the latest DST event as observed from EEST timezone:

The current implementation uses two fields to store the timestamps: the current date (as an integer offset form Progress Epoch) and time of day (as an int64 offset from midnight, in milliseconds). Although this has a clear advantage when it comes to inheritance, we struggle to recalculate back the correct components. Indeed, the 24H day is incorrect when the current day is recalculated in case of over/underflow of time for the day.

Maybe a better alternative is to keep the timestamp as a single field in datetime (as Unix Epoch Time) and extract date and time components as needed. The add/substract intervals would be trivial for fixed size units in this case. There is a problem here: the Unix Epoch Time does not cover the same range of timestamps as Progress date data-types. However, doing the date/time arithmetic using the Unix Epoch Time will probably fix the issue.

The right solution I believe is to use the new Java Time API. It provides date and timestamp with and without a time zone, which covers our needs in terms of storage and operations and offers a better integration with database persistence.