今日小发现,Python 的
下面的注释就很有意思 for historical reasons
然后就在issue里翻出了这个历史原因,开发者开始甩锅:“是97版的Posix标准先写错的,Python只是受害者!”
https://bugs.python.org/issue2568
之后直接开喷了
但是这些被坑的编程语言却没有跟着修正,只能作为historical reasons保留了
strftime()
支持61秒%S Second as a decimal number [00,61].
https://docs.python.org/3/library/time.html#time.strftime下面的注释就很有意思 for historical reasons
The range really is 0 to 61; value 60 is valid in timestamps representing leap seconds and value 61 is supported for historical reasons.
虽然是错了,但是也不是啥大问题就先不改了然后就在issue里翻出了这个历史原因,开发者开始甩锅:“是97版的Posix标准先写错的,Python只是受害者!”
https://bugs.python.org/issue2568
The 'double leap second' issue has been around a long time and is part
of the Posix standard (for some background see
http://www.ucolick.org/~sla/leapsecs/onlinebib.html, specifically the
section named 'Unix system time and the POSIX standard').
接着Posix标准说冤枉啊,是C89标准先写错的,我也是受害者啊:之后直接开喷了
The "double leap second" is complete nonsense. It never existed outside the
ANSI C standard and never will. It was introduced by the ANSI C 89 committee
to document its problems understanding UTC issues. Someone heard that there
are two prefered dates for leap seconds per year and this got munched up to
the false rumour that UTC days can be up to 86402 seconds long. The
definition of UTC, which requires that |UTC-UT1| < 0.9 s all the time,
obviously makes double leap seconds mathematically impossible.
最后,其实新的C99标准和04版Posix标准中都已经把时间范围从[0,61]修正为了[0,60],但是这些被坑的编程语言却没有跟着修正,只能作为historical reasons保留了