我在欧盟区 +1 或当夏令时已开启，+2。现在是 2024 年 3 月 31 日星期日。这周日早上，我们改为夏令时，2→3（英语四级考试→中欧夏令时）。
我的 Linux 服务器位于不同的网络中，在每月最后一天的 23:58 报告每月的能源消耗情况。它们多年来一直完美工作。网络间的旅行间隔长达 8 小时！
每个服务器都有一个实时时钟和同步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发行版，树莓派，不知何故有两个独立的内核函数计算时间。可悲的是，其中一个人错过了这一事实：今年是闰年！ 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"
答案1
好吧，我得到：
# date -s '2024-03-30 23:58'; date -d tomorrow
Sat Mar 30 23:58:00 EET 2024
Mon Apr 1 00:58:00 EEST 2024
这并不奇怪，因为 2024-03-30 23:58 之后 24 小时后是2024-04-01 00:58。只是后者是在夏令时。
手册说:
相关项目向前或向后调整日期（如果没有，则调整当前日期）。相关项目的影响会累积。
[...]
更精确的单位是[...]，“天”相当于24小时，
[...]
字符串“明天”相当于未来的一天（相当于“天”），
[.. .]
当相关项目导致生成的日期跨越时钟调整的边界（通常是夏令时）时，生成的日期和时间会相应调整。
避免此类问题的方法是请求一个不接近午夜的时间。
例如，中午通常是在正确的一天：
# date -s '2024-03-30 23:58'; date -d '+12 hours'
Sat Mar 30 23:58:00 EET 2024
Sun Mar 31 12:58:00 EEST 2024
这似乎也有效：
# date -s '2024-03-30 23:58'; date -d '12:00 tomorrow'
Sat Mar 30 23:58:00 EET 2024
Sun Mar 31 12:00:00 EEST 2024