我得到的抱怨是,在我的嵌入式设备中,华盛顿的PST时区要提前一小时.我正在使用tz实用程序来设置时区.
2018 Sun, Mar 11 at 2:00 am PST → PDT +1 hour (DST start) UTC-7h
Sun, Nov 4 at 2:00 am PDT → PST -1 hour (DST end) UTC-8h
我甚至用最新的2018二进制文件更新了tz实用程序,但仍然遇到了这个问题,我错过了其他的东西吗?
在4月1日检查PST-PDT的变化后我感到困惑?
usr/share/zoneinfo # date 031111002018; TZ='America/Los_Angeles' date
Sun Mar 11 11:00:00 UTC 2018
Sun Mar 11 03:00:00 PST 2018
/usr/share/zoneinfo # date 041111002018; TZ='America/Los_Angeles' date
Wed Apr 11 11:00:00 UTC 2018
Wed Apr 11 04:00:00 PDT 2018
PST-> PDT在4月1日凌晨2:00更改.
/usr/share/zoneinfo # date 040110242018; TZ='America/Los_Angeles' date
Sun Apr 1 10:24:00 UTC 2018
Sun Apr 1 03:24:00 PDT 2018
解决方法:
这听起来像您的设备正在使用太平洋新时区,这是一个在美国从未成为法律的提议时区,并指定在4月的第一个星期日转换为夏令时:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
## Rule Twilite XXXX max - Apr Sun>=1 2:00 1:00 D
## Rule Twilite XXXX max uspres Oct lastSun 2:00 1:00 PE
## Rule Twilite XXXX max uspres Nov Sun>=7 2:00 0 S
## Rule Twilite XXXX max nonpres Oct lastSun 2:00 0 S
由于各种原因,一些系统历史上最终使用此而不是正确的太平洋时区;例如,见this RISKS report(从1992年!)或this Debian bug(从2016年).在2018年的第一个tzdata版本中存在一些问题,可能在某些系统上引起了问题.从the release notes for 2018c:
The default installation procedure no longer creates the
backward-compatibility link US/Pacific-New, which causes
confusion during user setup (e.g., see Debian bug 815200).
Use make BACKWARD="backward pacificnew" to create the link
anyway, for now. Eventually we plan to remove the link entirely.
pacificnew文件设置从US / Pacific-New到America / Los_Angeles的链接,后向文件设置从US / Pacific到America / Los_Angeles的链接.因此理论上数据应该是正确的,但这取决于您的Los_Angeles文件包含的内容.
标签:linux,timezone
来源: https://codeday.me/bug/20190810/1639309.html