好吧，这是一个核心问题，我和我的朋友正在讨论正确的编程解决方案。
假设我在UTC-4时间在纽约经营一家公司。
我在旧金山的销售代表的时间是2013年12月31日下午11:00（我所在的时间是2014年1月1日凌晨1:00），他进行了一次销售，为公司净赚了1000000美元。他在系统中的销售发生在2013年12月31日，但实际上，在我的时代，它发生在2014年1月1日。
在我2013年的报告中，我是将1000000美元列为利润，还是将其计入我2014年的报告？
有一个相关的问题需要深入研究。。。大多数公司如何计算12月31日的日销售额？是公司总部时区从午夜开始的最后24小时，还是12月31日市场各时区的汇总时间？
此外，如果您只为销售输入了日期（YYYY-MM-DD），那么应该如何将其转换为UTC存储，因为一个UTC日期分布在两个唯一的日期上？
这里有一个我用来分析这个问题的有用工具：
http://everytimezone.com/#2013-8-27，-420,6bj
从实用的角度来看：
-
你在哪一个营业日记录下这笔交易可能并不重要。许多企业提前结束一天的工作，不一定是在午夜钟声敲响时。
-
有些企业可能使用总部的时区，有些企业可能会使用销售地点的时间。任何一种方法都可能有效。
-
当然，如果这是一个实际的问题，那么你应该询问会计师或税务律师。答案可能因行业、州或国家而异。
至于您问题的技术部分：
-
没有时间或时区的日期只是一个日期。把它想象成日历上的一个逻辑位置，而不是瞬间的一个独特时刻。
-
如果没有附加上下文，就无法将其转换为UTC。或者任何其他时区。
-
由于UTC是一个计时系统，而不是时区，因此从技术上讲，没有UTC日这回事，但这只是语义。尽管如此，"UTC日"的概念仍然只涵盖一个日历"日期"，因为这是"日期"定义的一部分
-
只是"UTC日"与"纽约日"不一致。就像"纽约日"与"洛杉矶日"并不完全一致一样。
-
更让你震惊的是，并不是每个当地的一天都是24小时。由于夏令时转换，"一天"可能长达23、23.5、24、24.5或25小时。当然，大多数都是"标准日"，也就是24小时。
-
如果你能把当地时间是日历上的一个位置，而瞬时时间是普遍的，那么你会发现这一切都是有意义的。
-
你提到的那个网站有一个很好的可视化，我经常引用它。但IMHO应该有一个不同的名称，因为它没有覆盖每个时区。小心使用。请参阅IANA数据库讨论的时区标签wiki，它有500多个区域。
-
我不知道你在使用什么语言或数据库，但你可能会发现我最近在这篇关于在RavenDB中使用日期和时间的文章中描述的概念很有用。具体来说，请阅读标题为"时区转换"的部分。即使你使用其他技术，同样的概念也会适用。