好的，这是一个核心问题，我和我的朋友正在讨论正确的编程解决方案。
假设我在 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 日分布在两个唯一的日期上？
这是我用来分析这个问题的有用工具：
从实际的角度来看：
您在哪个工作日记录销售可能并不重要。许多企业提前结束他们的日子，不一定在午夜钟声。
有些企业可能会使用其总部的时区，有些企业可能会使用销售地点的时间。任何一种方法都可能是有效的。
当然，如果这是一个实际问题，那么您应该询问会计师或税务律师。答案可能因您所在的行业、州或国家/地区而异。
至于您问题的技术部分：
没有时间或时区的日期只是一个日期。将其视为日历上的逻辑位置 - 而不是瞬时时间的独特时刻。
如果没有其他上下文，您无法将其转换为 UTC。或任何其他时区。
由于 UTC 是一个计时系统而不是时区，所以从技术上讲，没有 UTC 日这样的东西，但这只是语义。尽管如此，“UTC 日”的概念仍然只涵盖一个日历“日期”——因为这是“日期”定义的一部分。
只是“UTC 日”与“纽约日”不一致。就像“纽约日”与“洛杉矶日”并不完全一致。
更让你大吃一惊的是，并不是每个当地的一天都是 24 小时。由于夏令时转换，“一天”可能长达 23、23.5、24、24.5 或 25 小时。当然，大多数是“标准日”——正好是 24 小时。
如果你能把当地时间是日历上的一个位置分开，而瞬时时间是通用的，那么你会发现这一切都是有道理的。
你引用的那个网站有一个很好的可视化，我经常引用它。但恕我直言，它应该有一个不同的名称，因为它并不涵盖每个时区。小心使用它。请参阅 IANA 数据库讨论的时区标签 wiki，它有 500 多个时区。
我不知道您使用的是什么语言或数据库，但您可能会发现我最近在这篇关于在 RavenDB 中使用日期和时间的帖子中描述的概念很有用。具体来说，请阅读标题为“时区转换”的部分。即使您使用其他一些技术，同样的概念也将适用。