去年互联网地图行业开始引入众包模式，国内比较大的地图商，比如四维图新、高德地图、百度地图纷纷开始推出UGC应用，众包给用户采集门址、公交站等信息，并按照工作量给与采集者一定的回报。我曾经玩过某德推出的“道路寻宝”APP，应用内部集成了道路拍拍、门址采集、公交拍拍、POI任务等。该应用有如下限制：（1）为了防止作弊，采集者必须打开GPS，才能拍摄门牌号。（2）为了保证图片清晰，采集工作只能在日出后半小时至日落前半小时内进行。问题在于，应用仅仅读取手机的时间进行日出日落时间判断。有一次晚上参加用户线上会议，一位远在新疆的采集者抱怨，往往烈日当头采集就被强制结束。PS:其实还有一个BUG他没有发现：太阳升起之前，采集就已经放开了；而且如果你是位于东北三省东部的用户，在日落后依然可以采集~
那么问题到底出在什么地方？先从时区谈起。
理论时区
众所周知，由于时差问题，世界各地的日出日时刻是不同的。然而，每个国家或地区，都喜欢把日出时刻定在5-7点左右，把日落时刻定在17-19点左右。这样一来，使用全球统一的格林威治标准时间，就只能停留在专业领域，而在民用领域，大家各自为政，使用适合自己的时间。这就产生了时区。以穿越英国伦敦格林威治的本初子午线为基准，向东向西分别设置了12个时区，每个时区的“时间”数值相差一个小时。
理论时区以被15整除的子午线为中心，向东西两侧延伸7.5度，即每15°划分一个时区，这是理论时区。理论时区的时间采用其中央经线（或标准经线）的地方时。所以每差一个时区，区时相差一个小时，相差多少个时区，就相差多少个小时。东边的时区时间比西边的时区时间来得早。格林威治的0度经线，向东西各延伸7.5度，构成的15度范围组成的时区就是UTC±0，0时区所采用的时间就是格林威治时间，该时间也被采用为国际标准时间度量。东经7.5-22.5度为东一区，以此类推，西半球也采取相同的类推方式。东十二区和西十二区是重合的(172.5E - 172.5W)，国际日期变更线(180E/W)从中间穿越。从东向西穿越，日期加1天，西向东穿越，日期减1天。
法定时区
但是，国界线可不像经线、纬线那样平直。为了避开国界线，有的时区的形状并不规则，而且比较大的国家以国家内部行政分界线为时区界线，这是实际时区，即法定时区。于是，理论时区匀称、完美的划分，就变成了这样：（图片来自维基百科）
从图中可以看到，中国横跨了5个理论时区（从东五区 - 东九区），但是全部归在了法定时区UTC+8。美国的法定时区则尽量趋近于理论时区，因此就有了美东、美西、太平洋..等时间的区别。为了充分利用阳光，有的地区夏季会采用夏时制。我国曾采用了6年夏时制，但是由于我国将多个理论时区统一为东八区，因此新疆等天亮的较晚的地区并不能起到节约能源的作用，加上我国民众科学素养普遍不高，导致了更多的混乱，因此草草收场。
北京时间
某一国采用哪一个法定时区，一般取决于首都所在的理论时区。北京位于东八区，因此采用东八区中心经线（120E）所在位置的地方平太阳时（理论时间）作为法定时间，而不是北京的地方平太阳时（北京大致位于116E,40N附近）。上海位于120E,31N，几乎挨着东八时区的中央经线。
移动设备、计算机的时间是如何校准的？
众所周知，目前全球有为数众多的互联网授时服务，例如美国海军天文台授时中心，我国有中国科学院国家授时中心。这些授时服务提供的数据格式多种多样，比如从1970年1月1日到现在多少秒的整数。但这些授时中心采用的时间基准是GMT，即格林威治国际标准时间。我们电脑全新安装系统，或者手机、平板第一次启用，一般会有区域设置：“UTC+8，北京、香港、台北、新加坡”。设置完毕后，设备就可以换算出当地时间。
GPS时间
到这里相信很多人也都明白了。GPS模块（以Android手机为例，调用location.getTime()）获取的时间，是基于理论时区进行计算的当地理论时间。GPS卫星会广播当前的世界标准时间，然后根据经纬度算出所在理论时区，即可在线性时间内算出理论时区的当地时间。比如你人在新疆喀什，位于理论东五区，此时北京时间是上午10点，那么你的手机时间也是10点，但是GPS获取的时间则是7点（东八区 - 东五区 = 3小时时差）。
仅通过经纬度能否获取当地法定时间？
理论上可行。但是实际上非常困难：由于国界线的不规则性，要存储地球上某一点（假设是10米 * 10米面积的粒度）所在的国家或法定时区，数据量是非常庞大的，实际意义并不大。因此当前的解决方案，都是要求用户自己手动设置区域选项（而且大多是在初始化向导中强制设置）。夏时制的映射规则则要简单多了，因此一般都会有设备自行判断。
“道路寻宝”BUG的解决方案
第一，将当前时间获取方式改为通过GPS获取，就可以进行真正的日出日落判断。如果以时区为粒度，一般在理论上取早晨6点日出，18点日落，并在夏至、冬至前后进行适当调整。
第二，有些Android手机厂商开发的driver实在是太烂了，通过getTime可能获取不到当地理论时间，那么只有通过GPS读取的经度进行代码switch-case条件判断了：1
2
3
4
5
6
7
8
9
10
11
12
13switch(longitude)
{
case 67.5E-82.5E（理论东五区）: 使用当地理论时间即“手机时间（北京时间）- 3小时”判断;
case 82.5E-97.5E（理论东六区）: 使用当地理论时间即“手机时间（北京时间）- 2小时”判断；
.....；
case 127.5E-142.5E（理论东九区）: 使用当地理论时间即“手机时间（北京时间）+ 1小时”判断；// 黑龙江佳木斯市抚远县黑瞎子岛差不多就在134E，这里是中国最东端
}
更好的做法，就是在按照上述方式获得当地理论时间后，还要直接通过GPS经纬度，计算该点的日出日落时刻。因为该方式是精确到点的，因此计算的日出日落时刻和实际的日出日落时刻的误差只有几秒。而采用“6点日出18点日落”，误差有时会很大。这需要复杂的科学计算，用代码库可以实现。
更多
上述三条解决方案，保证了当地理论时间如何正确获取。还有一个问题，就是如何计算日出日落时刻，而简单采用“6点日出18点日落”也仅适用于春分、秋分前后，在冬至、夏至需要进行适当调整和近态拟合，否则计算日出日落时刻和实际日出日落时刻的误差会达到一个小时以上。
实际上，影响一个地方日出日落时刻的因素有很多，日期，纬度，海拔高度都需要考虑。要理解这些，需要专业的地理知识和科学计算，写起来又是长篇大论，所以此处略去一万字。大致规律是：越靠近赤道，日出/日落时刻越趋近于6点/18点；在任何地点，越接近一年当中的春分、秋分，日出/日落时刻同样越趋近于6点/18点；在北半球的夏季，越靠北，日出越早日落越晚，直到出现极昼现象。如果你的业务开展到俄罗斯北部，北极圈以内，那么请忘记日出日落吧~北半球冬季则正相反。南半球在季节上也与北半球相反。
地图应用背后的原理远不止这些。天朝特有的坐标扭曲和偏移也是一大问题，同国际标准的WGS84坐标系相比，国内地图商要交费使用保密的转换插件。
