[tz] make rearguard_tarballs fails on macOS
kre at munnari.OZ.AU
Mon Oct 19 04:13:31 UTC 2020
Date: Sun, 18 Oct 2020 14:37:57 -0700
From: Paul Eggert <eggert at cs.ucla.edu>
Message-ID: <1437ae48-9d51-c956-9b77-11ae29cbe2a1 at cs.ucla.edu>
| A better way to do it is to generate an internal format that
| tells you how much precision is in the timestamp.
Yes, I'd considered that for other reasons in the past (primarily as a
defence mechanism against people who insist in generating as much precision
as they seem able to produce, in effect getting semi-random digits after
a while). But creating yet another timestamp format isn't on my agenda
| Since text timestamps almost invariably use base 10 for
| subsecond information,
Yes, bintime was designed to deal with high res computer clocks,
which are binary, not decimal (which is why the "in kernel only"
remarks - by the time this info has escaped the kernel any high precision
accuracy it once held has been lost in the random nature of the
| the output of the timestamp parser should do likewise,
Yes, there's something in that, and it may be that I might use timespec
instead of bintime for that reason.
| and should say how many digits were in the input.
but I doubt I would be inventing a new format to allow that, and if
I were it would most probably be a bignum type format, so that it can
represent arbitrary precisions and not be limited to the number of bits
that were considered sufficient at the time the format was created.
I think we have drifted a bit far off topic, and well out of the realm
of civil timezones however.
More information about the tz