好的，这是一个硬核问题，我和我的朋友正在讨论正确的编程解决方案。
假设我在UTC-4时间在纽约开展业务。
我的销售代表总部设在旧金山，时间是2013年12月31日晚上11点（2014年1月1日凌晨1点，我的时间），这笔交易让公司罚款1,000,000美元。他于2013年12月31日进入系统销售，但实际上，在我的时间，它发生在2014年1月1日。
对于我的2013年度报告，我是否将1,000,000美元作为利润包含在内，还是将其纳入2014年的报告？
有关问题的相关问题......大多数公司如何计算12月31日的每日销售额？这是公司总部时区午夜的最后24小时，还是12月31日来自每个市场的时区聚合？
此外，如果您只为销售输入了日期（YYYY-MM-DD），那么如何将其转换为以UTC格式存储，即UTC日在两个唯一日期的分配？
这是我用来分析这个问题的有用工具：
答案 0 :(得分：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中描述的概念非常有用。具体来说，请阅读标题为“时区转换”的部分。即使您使用其他技术，也会应用相同的概念。