database - 日期处理的实践建议

Question

之前有个类似的话题:Daylight saving time and time zone best practices

我想问的是相关的，但又不同。

日期处理的建议做法是什么？

我正在寻找一个更“合乎逻辑”的日期。例如，我们应用程序的营业日期，或某些人的出生日期。

通常我将其存储为日期(在 Oracle 中)，时间为 0:0:0。如果我的应用程序的所有组件都在同一时区，这将正常工作。因为数据库中的那个日期意味着数据库时区的 0:0:0，如果我将我的数据呈现给另一个时区的用户，它很容易出现问题，因为例如 Date of 2012-12-25 0:0:0伦敦时间其实就是香港时间2012-12-24 16:0:0。

我想过两种办法解决，但都各有不足。

首先，我们将其存储为字符串。缺点很明显:我需要在我们的应用程序或查询中进行大量对话，并​​且丢失了很多日期算术

第二种方法是将其存储为日期，但具有预定义的时区(例如 UTC)。当应用程序显示日期时，它必须显示为 UTC 时区。但是，我需要在我的应用程序代码中进行大量时区操作。

处理日期的建议方法是什么？还是大多数人只是使用上述 3 种方法中的一种(包括假设相同时区的方法)？

Answer 1

日期是一种标识日期的方式，日期是相对于本地时区，即太阳。一天是 24 小时(尽管由于闰秒和其他恒星校正，24 小时只是一个非常接近的近似值)。因此，伦敦的 12 月 5 日与纽约的 12 月 5 日命名为不同的 24 小时周期。这样做的后果之一是，如果你想对不同时区之间的日期进行算术运算，你只能做到 +/- 1 的精度。作为一种数据结构，这是一个传统的日期(比如，年和天偏移量)和由与 UTC 的小时偏移量标识的时区(请注意，那里有一些 1/2 小时的偏移量)。

应该很清楚，那么将一个时区的日期转换为另一个时区的日期是不可能的，因为它们代表不同的时间间隔。 (大多数情况下。相邻时区可能会有异常(exception)，一个是夏令时，一个不是。)出于同样的原因，不同时区之间的日期算术也不能正常进行。有时没有捕获足够的数据来获得完美的答案。

但是，对于您提出的问题背后的疑虑，完整答案取决于日期的含义。例如，如果它们是诸如截止日期之类的法定日期，那么这些日期通常是根据办公楼的位置获取的，例如截止日期所在的位置。在那种情况下，日期边界遵循单个时区，冗余存储它没有任何意义。时间将在存储时转换为该时区的日期。