计算每日和每年利润的时区问题答案

【问题标题】：Time Zone Issues with Calculating Daily and Yearly Profit计算每日和每年利润的时区问题
【发布时间】：2013-08-30 22:47:05
【问题描述】：

好的，这是一个核心问题，我和我的朋友正在讨论正确的编程解决方案。

假设我在 UTC-4 时间在纽约经营一家企业。

我在旧金山的销售代表，其时间是 2013 年 12 月 31 日晚上 11:00（我的时间是 2014 年 1 月 1 日凌晨 1:00）进行的销售为公司净赚了 1,000,000 美元。他在 2013 年 12 月 31 日进入系统中的销售，但实际上，在我的时代，它发生在 2014 年 1 月 1 日。

对于我的 2013 年报告，我是否将 1,000,000 美元作为利润包括在内，还是将其包含在我的 2014 年报告中？

一个相关的问题来解决这个问题......大多数公司如何计算 12 月 31 日的每日销售额？是公司总部时区午夜后的最后 24 小时，还是每个市场时区的 12 月 31 日的总和？

此外，如果您只输入日期 (YYYY-MM-DD) 进行销售，那么应该如何转换以 UTC 存储，因为 UTC 日分布在两个不同的日期上？

这是我用来分析这个问题的有用工具：

http://everytimezone.com/#2013-8-27,-420,6bj

【问题讨论】：

标签： datetime time timezone timezone-offset date-arithmetic

【解决方案1】：

从实用的角度来看：

您在哪个工作日记录销售可能并不重要。许多企业提前结束他们的日子，不一定在午夜钟声。
有些企业可能会使用其总部的时区，而有些企业可能会使用进行销售的地点的时间。任何一种方法都可能有效。
当然，如果这是一个实际问题，那么您应该咨询会计师或税务律师。答案可能因您所在的行业、州或国家/地区而异。

就您问题的技术部分而言：

没有时间或时区的日期只是一个日期。将其视为日历上的一个合乎逻辑的位置 - 而不是瞬时时间的独特时刻。
如果没有其他上下文，您无法将其转换为 UTC。或任何其他时区。
由于 UTC 是计时系统而不是时区，因此从技术上讲，不存在 UTC 日，但这只是语义。尽管如此，“UTC 日”的概念仍然只涵盖一个日历“日期”——因为这是“日期”定义的一部分。
只是“UTC 日”与“纽约日”不一致。就像“纽约日”与“洛杉矶日”并不完全一致。
更让您大吃一惊的是，考虑到并非每个当地的一天都是 24 小时。由于夏令时转换，“一天”可能长达 23、23.5、24、24.5 或 25 小时。当然，大多数都是“标准日”——正好是 24 小时。
如果你能区分当地时间是日历上的一个位置，而瞬时时间是通用的，那么你会发现这一切都是有道理的。
您引用的那个网站具有很好的可视化效果，我经常引用它。但恕我直言，它应该有一个不同的名称，因为它不涵盖每个时区。小心使用它。请参阅 IANA 数据库讨论的 timezone tag wiki，它有超过 500 个区域。
我不知道您使用的是什么语言或数据库，但您可能会发现我最近在this post on working with Date and Time in RavenDB 中描述的概念很有用。具体来说，请阅读标题为“时区转换”的部分。即使您使用其他一些技术，同样的概念也适用。

【讨论】：