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 ran. - Time in current process. Time from when this Scheme session started. - Durations. Arbitrary amounts of time. - Other, implementation specific representations (time spent in GC, etc.) - 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: UTC<->TAI<->Date Monotonic->UTC Monotonic->TAI Monotonic->Date 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" http://www.cl.cam.ac.uk/~mgk25/c-time/. -- Will