Date: Sun, 18 Oct 2020 14:37:57 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <1437ae48-9d51-c956-9b77-11ae29cbe2a1@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 right now. | 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 processing). | 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. kre