夏令时

2019-09-07

World_Time_Zones_Map.png

设计给老外发通知邮件的时候,遇到了时区问题。

我看了一下表,现在北京时间 19:00,西雅图比北京晚 15 小时,于是 19 - 15 = 4 ,西雅图是 4:00。打开世界时钟验证一下,西雅图果然是 4:00,计算正确。

北京时间 19:00 有一节课,就发邮件给西雅图的老师说,你在 4:00 有节课,是不是就可以了?

好像是没毛病。不过印象中我用的美股交易软件,提醒过用户美国进入夏时令什么的然后美股开盘收盘都提前一小时。记不太清了,我就请教了曾在北美留学的同事。她说了几句也没解释清,又问了旁边的歪果仁,还是没讲明白。我一看算了,老外这脑子不一定行。还是问问在美国定居的老同学孙忱吧,就发了条微信给他。

很快便收到回复,孙忱几句话就讲明白了 daylight saving 的本质,不愧是谷歌的大神。但我自己还想进一步搞清楚,为什么要有夏令时这么奇怪的设定?

刚才说了,今天(9月6日)北京时间 19:00,西雅图是 4:00,相差 15 个小时。但到了冬季,北京 19:00 对应的就是西雅图 3:00,相差就不是 15 小时了,而是 16 小时。

时间是协同大家步调的重要参考,必须力求精确,夏令时从哪天开始,到哪天结束,必须要有一个说法。我上网一查,说法倒是有,只是远不止一个。长图预警:

daylight-2019.png

daylight-2020.png

犹如电影结束后长长的演员表,那么恭喜你坚持到了后面的彩蛋。

通过上面的长图可见,夏令时的起止日期,在不同年份不一样,不同国家也不一样,甚至同一国家的不同地区也有差别,拿美国为例:

美国不实行夏令时的州及领土包括:夏威夷、美属萨摩亚、关岛、波多黎各、美属维京群岛以及除去纳瓦霍人保留地社区之外的亚利桑那州。

至此终于明白,时区偏移可不是简单几条规则就能搞定的,不由得产生了敬畏。

程序一般都可以获取到用户时区,以 JavaScript 为例:

Intl.DateTimeFormat().resolvedOptions().timeZone

如果是在北京,这个返回值就是字符串 Asia/Shanghai,如果在西雅图就是 America/Los_Angeles

然后用这个时区字符串就可以做转换:

time = new Date('2019-09-06T19:00:00') // 本地北京时区晚上 7 点
time.toLocaleString('en-US', {timeZone: "America/Los_Angeles"}) 
// 转换成西雅图时间,是凌晨 4 点

夏令时差15个小时,是对的。下面试试非夏令时,我们换一个冬天的时间:

time = new Date('2019-12-06T19:00:00') // 本地北京时区晚上 7 点
time.toLocaleString('en-US', {timeZone: "America/Los_Angeles"}) 
// 转换成西雅图时间,是凌晨 3 点

从结果看到,程序能自动识别出夏令时/非夏令时,特别省心对不对。


关于夏令时的由来,英文 daylight saving 表达的很清楚,就是为了节约日光。少浪费日光,就能少耗费电灯的电能。乍一看有道理,但综合起来看其实弊大于利,网上关于它的吐槽有很多,我就不啰嗦了。

说到底,还是节约意识太强害的。太会过日子了。有一件事我是查了资料才知道,那就是中国——这个非常节俭的国家——也实行过好几年的夏令时。就发生在我小时候,而我竟然完全没有印象!小孩子真的是只知道玩啊。

1.jpeg 2.jpeg 3.jpeg 4.png 5.png

END