On Sat, May 11, 2019 at 6:48 AM Lassi Kortela <xxxxxx@lassi.io> wrote:

Should we just return all timestamps (file time, current time of day,
anything else) as two nonnegative integers: [seconds nanoseconds]?

I agree that two integers makes sense, but returning multiple values is problematic. They are harder to handle, requiring special syntactic machinery, and do not have the property (as they do in Common Lisp) that a continuation expecting a single value will discard any additional values; indeed, it it is an error to do that. <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/MultipleValues.md> details which Schemes do and do not safely discard excess values. So I would rather return an object.

However, an actual abstraction barrier is probably not really necessary either. I would be happy to go with a simple (second . nanosecond) pair, which is usually implemented very efficiently both in construction and in access. This is MIT Scheme's internal representation, and it is not inconsistent with SRFI 18, which does not require an abstraction barrier, just that time objects be distinguishable from numbers. I don't feel super-storngly about this, though.

All timestamps would have nanosecond precision, and the accuracy of
the nanoseconds part is "make of it what you will". We would not
provide procedures to ask "how precise is the nanosecond part really?"

Agreed.

FAT stores last modified timestamps with two-second precision,
UFS stores with nanosecond precision (which no computer can actually
supply it). Both are "advertised" by stat() as having nanosecond
precision.

On NTFS, the precision of the last-access timestamp is 1 day!

(current-nanosecond) ---> [secs nsecs]

I would add this procedure by analogy to current-second in R7RS.

I would prefer "posix-time". The R7RS-small procedure (current-second) is TAI, has a different epoch, and is an inexact number, and we want to keep that very clearly separated from this.

(time+ticks) ---> [secs ticks]

I would leave out this procedure that combines a precise second with a
variable-precision sub-second tick counter:

I agree that this is now unnecessary with standardization on nanoseconds.

On Sat, May 11, 2019 at 8:04 AM Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:

As time passes, the (fixed) 52 significant bits of a 64 bit flonum will represent the seconds since the epoch with increased error.

Indeed, IEEE binary64 format could only represent nanosecond precision until April 14, 1970. That puts all the precision long ago and very nearly in a galaxy far, far away. 64-bit seconds and 32-bit or 64-bit nanoseconds will take us to the Big Crunch (assuming there is one) and with constant precision.

By that time architectures will probably have evolved to 128 bit flonums

I'm not so certain of that. Integer range tends to be driven by bus widths, but float precision and range by the needs of scientific work. 64-bit (though non-IEEE) floats have been around since 1964 at least, with no sign of 128-bit floats in common use yet. Even the much more useful decimal floats are taking approximately forever to catch on: they were first published 16 years ago and standardized 11 years ago.

(alternatively a new epoch could be defined to reset the error).

Not if we are to believe Vernor Vinge's _A Deepness in the Sky_: "Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later."

That's many millennia down the timeline, or long enough for Pham Nuwen and the other founders of the Qeng Ho to have forgotten how to spell Admiral 郑和 Zheng He's name. :-) (It was spelled "Cheng Ho" in Wade-Giles romanization, which Vinge converted to Pinyin incorrectly.)

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org

We are lost, lost. No name, no business, no Precious, nothing. Only empty.

Only hungry: yes, we are hungry. A few little fishes, nassty bony little

fishes, for a poor creature, and they say death. So wise they are; so just,

so very just. --Gollum