[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Note #1: The basic representation of time

This page is part of the web mail archives of SRFI 19 from before July 7th, 2015. The new archives for SRFI 19 contain all messages, not just those from before July 7th, 2015.

Note #1. The basic representation of time.

"Time" is an absolute (Newtonian) point in time. There are a number of
standard time representations that should be captured:

- TAI (international atomic time). Measures constant, real time.
- UTC (coordinated universal time). TAI adjusted by leap seconds.
- Monotonic time. Time from some point in time since this computer was
last reset.
- Time in current thread. Time from some point in time since this thread
- Time in current process. Time from when this Scheme session started.
- Durations. Arbitrary amounts of time.
- Other, implementation specific representations (time spent in GC,
- Other, user-defined representations (mission elapsed time, etc.).

You should be able to query the representation for its resolution.

"Time" should be its own data type, with three fields:

The 'type,' i.e., the representation type described above,
A number of seconds, an integer, representing the number of whole
seconds since/before the 'epoch' or start of the point in time,
A number of nanoseconds, an integer (0 to 999,999,999) representing the
partial seconds. Leap seconds, though, are represented in the nanosecond
field as 'overflow' to 1,999,999,999.

Conversion procedures required:


Getting the current time is only required to provide a 'best effort'.

Some justifications:

I won't try to justify each of the representations, except that I do
think it's important to allow a 'user defined' time types.

Using seconds/nanoseconds provides a clean, consistent, precise,
representational scheme that is likely to work for a long time
(milliseconds may be too little; attoseconds too much). Querying the
resolution allows you to know how much really matters.

Representing leap seconds as 'overflow' means that the 'seconds' part of
TAI and UTC forms will be the same as far as conversion routines go.

Carrying the 'type' with the datum helps prevent invalid operations
(like adding two TAI times).

Relativity isn't considered because, well, then I'd have to understand
relativity, and I'm just a liberal arts convert :)

It's difficult to get the current time, especially in the absence of
time servers, etc.

Much of this is based on "Proposed new <time.h> for ISO C 200X"