New Issue: Stabilization of timeSinceEpoch

Notifications Issues
1

19098, "ben-albrecht", "Stabilization of timeSinceEpoch", "2022-01-25T18:36:33Z"

(split off from `DateTime` module stabilization - removing ambiguous functions · Issue #18834 · chapel-lang/chapel · GitHub)

Background on timeSinceEpoch

In the stabilization of the Time module (https://github.com/Cray/chapel-private/issues/1320), we decided that we would deprecate getCurrentTime since similar functionality is available in the DateTime module: datetime.now().

However, there were 2 issues with this replacement:

  1. Getting the DateTime version to output the same format our getCurrentTime required a more complicated replacement:
(datetime.now() - datetime.now().replace(hour=0,minute=0,second=0,microsecond=0)).total_seconds()
  1. getCurrentTime gets the time since midnight, which isn't generally useful (Time.getCurrentTime behavior isn't generally useful · Issue #14571 · chapel-lang/chapel · GitHub).

Therefore, it was proposed that we support a more useful "time since unix epoch" function, which should still effectively act as a drop-in replacement for the deprecated getCurrentTime. This was added as datetime.timeSinceEpoch in Chapel 1.25.

Proposed changes

Later on in the stabilization review of DateTime, it was agreed that timeSinceEpoch is a proc type on datetime to return a real and doesn't pertain to the datetime type in any way. Therefore, the following has been proposed:

  1. timeSinceEpoch be separated out into a standalone function
  2. timeSinceEpoch be moved to another module, such as the module that contains Stopwatch