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

Question

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

假设我在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日的日销售额的？

此外，如果您只输入了销售日期(YYYY-MM-DD)，那么应该如何将其转换为存储在UTC中的日期，因为UTC日期分布在两个唯一的日期中？

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

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

Answer 1

从实际的角度来看：

• 你在哪个工作日记录了这笔交易，这可能并不重要。
• 许多公司可能会使用总部的时区，而有些公司可能会使用销售地点的时间。当然，如果这是一个实际的问题，你应该去问一个会计或者税务律师。
• ，当然，如果这是一个实际的问题，那么你应该去问一个会计或者税务律师。根据行业、州或国家的不同，答案可能会有所不同。

至于你问题的技术部分：

• 没有时间或时区的日期只是一个日期。把它想象成日历上的一个逻辑位置--而不是一个独特的瞬间time.
• Without附加上下文，你不能把它转换成协调世界时。或者任何其他时区，对于那个协调世界时来说，是一个计时系统，而不是一个时区，那么从技术上讲，就不存在协调世界时这样的东西，但这只是语义上的。尽管如此，“协调世界时日”的概念仍然只包括一个日历“日期”-因为那是“日期”定义的一部分。
• 只是“协调世界时日”与“纽约日”不一致。就像“纽约日”和“洛杉矶日”并不是完全一致的。
• 让你更吃惊的是，考虑到并不是每个本地的一天都是24小时。由于夏令时的转换，“一天”可能会缩短23、23.5、24、24.5或25小时。当然，大多数是“标准日”--准确地说是24小时。
• 如果你能把本地时间是日历上的一个位置，而即时时间是通用的，那么你会发现这一切都是有意义的。
• 你引用的那个网站有一个很好的可视化效果，我经常引用它。但是我想它应该有一个不同的名字，因为它不能覆盖每个时区。小心使用它。
• 我不知道您使用的是哪种语言或数据库，但您可能会发现我最近在this post on working with Date and Time in RavenDB中描述的概念很有用。具体来说，请阅读标题为“时区转换”的部分。即使您使用其他技术，同样的概念也将适用。