[tz] Fractional seconds in zic input
zefram at fysh.org
Mon Feb 5 12:31:00 UTC 2018
Howard Hinnant wrote:
>If we are to add fractional second support, it should come with a
>specification of the precision, or precision-range that is supported
>(e.g. centiseconds, milliseconds, whatever). Without such documentation,
>3rd party zic compilers will have to make an assumption
No, there is no such necessity. Anything that parses the zic input format
will need to round values to the resolution of its output format, which
for mainline zic is the 1 s resolution of the tzfile format. It is not
a problem for such a parser that the string input format can extend to
Your comments would make a lot more sense if we were discussing a change
to the tzfile format to accommodate fractional seconds. (We probably will
have such a change in due course.) To be consistent with the existing
nature of the file format, we'd most likely have a defined resolution
for subsecond times.
>And I am in midstream of attempting to base an international C++
>language standard on the syntax and semantics of this database.
The obvious choice there would be something like POSIX's struct timespec.
Fixed resolution defined as part of the API. It doesn't make sense to
try to squeeze the subsecond part with the integer part into 64 bits:
we're already settled on 64 bits for the integer part alone. Follow the
consensus of using a separate fractional part, with a decimal-based
resolution, at least as fine as existing APIs (1 ns).
Your API design doesn't have to precisely match the resolution of tzfile
(of any version), let alone anything further upstream. It would be good
for it to be at least as fine as whatever we eventually put into tzfile,
but even that isn't vital.
More information about the tz