天气相关的时间计算

考虑下面的用户案例：

 老人想从北京飞去纽约，28日上午他做了天气查询，他想知道到达纽约后应该穿什么衣服，此时我们的 app 应该给出的是纽约 27 日的日天气概况。

由此可以引申出来，当地天气应该和当地时间联系的原则。

但是在天气相关的时间计算里，有各种复杂的情况，仅仅举几个例子：

• 日出、日落的计算，依赖于当地的地理上的本地时间
• 紫外线指数的计算，需要计算当地的地理上的正午时间
• 计算某一天的天气概况，比如最高温、最低温、平均气温，需要有一个相应的统计时间起点和终点
• 当地居民日常生活的时间参考，依赖于当地的行政区划上的时间设置
• 手机用户可能会去观察一个其他地点的天气状况，可能是地理上非常遥远的城市
• 夏令时（Daylight Saving Time ）是否考虑？

概括起来，时间上的参考系统有如下四种：

• 当地地理上的本地时间系统
• 当地行政区划上的时间系统
• 观察者行政区划上的时间系统
• 夏令时（DST）

在 API v2.3 中，我们采用如下的原则来使用这些时间参考系统：

• 任何天气现象相关计算中都采用 Unix 时间戳，使用和当地地理上的本地时间系统来进行有关计算
• 任何给用户的 API 输出里，相关的时间都采用当地行政区划上的时间系统，时间的文字表示遵循 ISO8601 标准
• 不使用观察者行政区划上的时间系统
• 不使用夏令时

API v2.3 尚在测试中，存在如下已知 bug：

• 极圈内的极昼和极夜的情况下，日出和日落时间是错误的

我们计划在 API v2.4 中彻底解决日出日落计算的国际化问题。

在解决方案中，我们会考虑引入：

• 当地行政区划上的中午时间：也就是太阳位置最高的时间（upper culmination）
• 当地行政区划上的午夜时间：也就是太阳位置最低的时间（lower culmination）

请参照 https://en.wikipedia.org/wiki/Culmination

我们建议用如下的 API 数据结构

sun: [
    {
        datetime: "2018-11-10T17:03+08:00",
        eventtype: "rise",
    },
    {
        datetime: "2018-11-10T17:03+08:00",
        eventtype: "upperculmination",
    },
    {
        datetime: "2018-11-10T17:03+08:00",
        eventtype: "set",
    },
    {
        datetime: "2018-11-10T17:03+08:00",
        eventtype: "lowerculmination",
    }
]

这个结构的好处是，将来可以拓展到月球、大行星和亮星。