本文深入探讨了在国际化应用中处理日期和时间的复杂性，包括时区、日界线、夏时制、时刻、格林威治标准时间（GMT）、协调世界时（UTC）、日历系统以及时间表示格式。强调了只存储和传输时刻的重要性，以及在编程中避免使用“日期”概念，以防止时区混淆和数据错误。同时，提出了处理时区差异和确保数据一致性的策略。
在国际化应用中，对日期/时间的处理远比你想象中的更难，特别是当涉及到时区的时候。为什么会这么难？我们该如何解决它？请听我为你一一解析。
几乎所有的系统都离不开“时间”的概念，以至于大多数语言（及其默认库）都定义了日期/时间等类型。
但是，我们日常所说的“时间”这个词实际上包含了多个相似却有微妙差异的概念。如果不能分清它们，会给你的开发工作带来很多烦恼。
基本概念
时区（Timezone）
在应用系统中，对时间的混淆往往和时区有关。这是很多系统从本地化应用发展成全球化应用时的一大障碍。
由于各地日出日落的时刻不同，所以全球一共分为 24 个时区，每个时区横跨 360/24=15 个经度。比如伦敦位于北京的西面，那么当北京的太阳已经升起的时候，伦敦还要再过 8 小时才能迎来黎明。也就是说，伦敦比北京晚 8 小时。而东京位于北京的东面，所以东京的日出比北京早 1 小时。
如果我们想知道当北京是中午 12:00 的时候，东京是什么时间，可以先用 12:00 减去当前时区 +08:00，换算成伦敦时间 04:00，再加上目标时区 +09:00，就得到了东京时间 13:00。
零时区
地球是圆的，北京比伦敦早8小时其实就等于比伦敦晚16小时，到底谁比谁早呢？我们既可以把这个时差表示为+8，也可以表示为-16，到底该怎么写呢？我们要先确定一个标准。
首先，要确定一个零时区。
虽然任何一个地方都可以作为零时区，但拥有世界上第一座航海钟的英国格林威治天文台夺得了这项殊荣，而经过那里的子午线（经线），被称为本初子午线。它左右各7.5度的范围叫做零时区，再往西一个时区就叫做西一区。
当我们自东往西旅行的时候，是在追着太阳走，因此每过一个时区，就要把表拨慢一个小时才能跟当地时间保持一致，我们把这个“拨慢”的动作，记作 -01:00，反之则是 +01:00。如果从伦敦往北京走，需要从西往东走八个时区，因此北京的时区就记作 +08:00。
日界线（国际日期变更线）
在球面上，与它相对的那条子午线，正好是 +12:00 区和 -12:00 区的分界线。这条线很特殊，因为当你自西向东越过它的时候，既是比伦敦早了13小时，从另一个方向来看，也是比伦敦晚了11小时。就像数学中的进位一样，它们的日期应该是不同的。当自西向东越过日界线的时候（迎着朝阳），日期应该减一，反之（追赶夕阳），则应该加一。
假设有一个人于中午 12:00 坐飞机从伦敦出发，自东向西（追着太阳）做环球旅行。以这架飞机的速度，恰好每小时飞过一个时区，于是，每过一个小时，他都要把表拨慢一个小时（-01:00）。换句话说，我们的主人公一直生活在中午 12:00，而太阳也确实一直在他的头顶，他的感知时间和表上的时间是一致的，这样就避免了他顶着大太阳说“现在是午夜”的荒谬感。但是，当他到达日界线的时候，还要做另一件事。由于他是在自东向西穿越日界线，所以他还要把日期加一。他继续向前，等回到伦敦走下飞机的时候，他表上的时间是第二天中午 12:00，而当地时间也恰好是第二天的 12:00，他自己恰好在天上飞了一整天。这样，所有的时间就都对上了。
但是如果我们仔细看时区表，就会发现有些时区被标记为+13:00
最低0.47元/天 解锁文章
扫一扫
770
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
