我在欧盟区 +1 或DST开启时 +2。现在是 2024 年 3 月 31 日星期日。这周日早上，我们改为 DST，时间为 2→3（CET → CEST）。
我的 Linux 服务器位于不同的网络中，在每月最后一天的 23:58 报告每月的能源消耗情况。它们多年来一直完美工作。网络间的旅行间隔长达 8 小时！
每个服务器都有一个RTC并定期同步NTP 。如果有任何可疑的情况，有很多保障措施，每个网络中的三台核心服务器不断相互检查一切（包括时间）是否正常。是的，我很偏执。我不允许 (0) 个错误。我的系统可以完美稳定地运行很多年。工作了，抱歉。
昨晚，3 月 30 日 23:58，我所有的 Raspberry Pi 服务器决定 3 月 30 日之后是下个月 1 日！我验证了每个网络的 7（七）种不同且独立的方式，一切确实发生在 3 月 30 日 23:58 分钟内！确认包括 9 个忽略 DST 的独立设备，以及一个外部美国和欧盟邮件提供商。
每天 23:58，我的服务器都会进行 bash 测试，显然可能会在很多方面出错：
(( $(date -d tomorrow +"%-d") == 1 )) && ZadnjiDanMjeseca=1 || ZadnjiDanMjeseca=""
我看不出这个测试有任何出错的地方！我希望我错了。此时此刻，2024 年 3 月 31 日。一切都工作得很好，zdump 是正确的！（以下示例对我来说似乎格式错误。必须显示四个不同的行。）
hwclock; date; date -d tomorrow +"%-d"
2024-03-31 19:22:23.311664+02:00
ned, 31.03.2024. 19:22:23 CEST
1
我可以解释这个问题的唯一方法是：我使用的 Linux 发行版Raspbian不知何故有两个独立的内核函数计算时间。可悲的是，其中一个人错过了这一事实：今年是闰年！UPS！
但是，如果是这样，为什么要限制为这个 Raspberry Pi 操作系统版本和内核呢？天哪，微软没能让Excel正确计算闰年！
这个周末，我看到我国的几家机构（银行、我们的国家税务局……）都出现了与日期相关的问题，并且也关闭了商店，所以这似乎不仅限于 Raspbian。
这对我作为程序员来说是不利的，但是，我找不到其他解释。希望我错了......
在发帖之前，我从 1 日的 23:58 切换到 00:03，并且我必须在该月最后一天的 23:58 记录数据，我通过添加 300 秒进行测试，而不是要求 +1天。这些解决方案应该有效。
所以它没有被隐藏在评论中：由于我从来没有使用过这样的计算，所以我犯了一个基本错误，期望“明天”实际上意味着明天！这对我来说没有任何意义；这意味着+1天。因此，我预计这两个命令会产生相同的输出：
> date -d 'next tue'
uto, 2.04.2024. 00:00:00 CEST
> date -d 'tomorrow'
uto, 2.04.2024. 10:24:55 CEST
而不必输入：
date -d "tomorrow 0"
好吧，我得到：
这并不奇怪，因为 2024-03-30 23:58 之后的 24 小时就是2024-04-01 00:58。只是后者是在夏令时。
手册说：
避免此类问题的方法是请求一个不接近午夜的时间。
例如，中午通常是在正确的一天：
这似乎也有效：