解决方案

Question 1

正如其他人所说，浮点数的大多数十进制表示形式无法精确地以计算机用于计算的二进制格式表示。

您看到的printf %.55f只是原始数字的二进制近似值的十进制表示形式。

您的printf（可能的）内置命令使用转换1662665413.471669572为long double二进制表示形式strtold()，然后将其传递给printf()函数（或该系列中的其他函数，例如snprintf()）进行格式化（%.55f更改为%.55Lf）

表示方式long double因系统、C 编译器和 C 编译器以及 CPU 架构而异。对于printf在 amd64 硬件上的 GNU/Linux 系统上使用 GNU cc 编译的 /shell，长双精度数具有足够的精度来以纳秒精度保存当前时间戳。

但是许多（如果不是大多数）工具和语言，包括大多数 awk 实现、perl、大多数 shell（对于那些支持浮点运算的 shell，而不是 bash）都使用双精度数而不是长双精度数，并且双精度数总是只有 53 位精度，因此精度不能超过 15 位小数1.

这就是为什么大多数处理高精度时间戳的东西实际上用两个整数表示它们的原因之一：秒数和微秒数（如系统struct timeval调用返回的值gettimeofday()）或纳秒（如系统struct timespec调用返回的值clock_gettime()）。

这就是为什么 GNUdate有%sand 而%N不是的浮点变体%s，为什么 zsh 有$epochtime数组而不是浮点数。

要使用如此高精度的时间戳进行计算，如果您的语言/工具不使用 long double，或者在不使用 CPU 浮点运算（例如bc）的情况下不以十进制进行任意精度计算，则可以以整数进行计算。

大多数 shell 都会使用 64 位整数进行整数运算long，最多可以容纳 9223372036854775807 的数字。

例如，要计算两个时间戳之间的差异（将每个时间戳表示为（秒，纳秒）元组），您可以(sec2 - sec1) * 100000000 + nsec2 - nsec1获取以纳秒为单位的差异。

例如，在 zsh 中：

zmodload zsh/datetime
start=($epochtime)
uname
end=($epochtime)
print running uname took about $((
  (end[1] - start[1]) * 1_000_000_000 + end[2] - start[2] )) nanoseconds.

这里给出：

Linux
running uname took about 2621008 nanoseconds.

您可能会争辩说，在 shell 中拥有如此高的精度，运行任何非内置命令（包括date）至少需要几千纳秒，这几乎没有意义。

像：

zmodload zsh/datetime
start=$EPOCHREALTIME
uname
end=$EPOCHREALTIME
printf 'running uname took about %.5g seconds\n' $(( end - start ))

其中$EPOCHREALTIME具有完整的精度，因为它是通过将秒和纳秒（0 填充）整数与中间值连接起来而构建的，但是在转换为进行计算.时会丢失一些精度，这可能已经足够好了。double

尽管在这里，就像在 ksh93 中一样，您宁愿这样做：

typeset -F SECONDS=0
uname
printf "running uname took %g seconds\n" $SECONDS

（$SECONDS，保存自 shell 启动以来的时间可以设为浮点（并重置为秒表），在这种情况下，您可以获得微秒精度）。

^{1 例如，printf使用doubles 而不是long doubles 的aprintf %.16g <a-16-digit-number>不能保证给您相同的数字（例如尝试使用9.999999999999919和printfofzsh或gawk）perl。}

Answer