在回顾我过去的答案时，我注意到我提出了这样的代码：
import time
def dates_between(start, end):
# muck around between the 9k+ time representation systems in Python
# now start and end are seconds since epoch
# return [start, start + 86400, start + 86400*2, ...]
return range(start, end + 1, 86400)
重读这段代码时，我情不自禁地感觉到小马托尼可怕地触碰了我的脊椎，在我耳边轻声喃喃着“闰秒”之类的可怕、可怕的事情。
对于“秒”的时代定义，“一天是 86,400 秒长”的假设何时打破？（我假设 Python 之类的函数time.mktime已经返回了 DST 调整后的值，所以上面的代码片段也应该在 DST 切换日工作......我希望？）
每当进行日历计算时，几乎总是使用平台提供的任何 API，例如 Python 的datetime和calendar模块，或者成熟的高质量库，而不是自己编写“更简单”的代码。日期和日历 API 丑陋而复杂，但这是因为现实世界的日历有很多奇怪的行为。
例如，如果现在是“上午 10:00:00”，那么到“明天上午 10:00:00”的秒数可能会有所不同，具体取决于您使用的时区， DST 今晚是开始还是结束，等等。
每当常量 86400 出现在您的代码中时，您很有可能正在做一些不太正确的事情。
当您需要确定一周、一个月、一年、一个季度等的秒数时，事情会变得更加复杂。学习使用这些日历库。
根据维基百科，
UTC 天数几乎总是 86 400 秒，但由于“闰秒”偶尔为 86 401 秒，可能长达 86 399 秒（尽管截至 2010 年 12 月从未使用过后一种选项）；这使日子与地球自转（或世界时）保持同步。
我希望双闰秒实际上可以使一天 86402s 变长，如果它曾经被使用的话。
再次编辑：由于混淆了python文档，第二次猜到了自己。 time.mktime总是返回 UTC 纪元秒。完成了。:)
一天中的秒数取决于您使用的时间系统，例如，在 POSIX 中，一天的定义正好是 86400 秒：
从纪元开始以秒为单位表示，每一天都应准确计算为 86400 秒。
在 UTC 中，可能包含闰秒，即一天可以是 86401 SI 秒（理论上是 86399 SI 秒）。截至 2015 年 6 月 30 日，已发生 26 次。
如果我们通过太阳的视运动来测量天数，那么（太阳）日的长度在一年中与平均值相差约 16 分钟。
反过来，它与同样基于地球自转（平均太阳时）的UT1不同。一个视太阳日可以比平均太阳日短 20 秒或长 30 秒。通过引入偶尔的闰秒，UTC 保持在 UT1 的 0.9 秒以内。
如果您按当地时钟定义一天，那么由于奇怪的政治时区变化，它可能会非常混乱。假设由于 DST，一天可能仅改变一个小时是不正确的。
在“支持”夏令时的所有时区中，您每年都会有两天没有 24 小时。他们将分别有 25 小时或 23 小时。甚至不要考虑对这些日期进行硬编码。它们每年都在变化，并且在不同时区之间变化。