Database 数据处理的实践建议

之前也有类似的话题：

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

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

我在寻找一个更“合理”的约会。例如，我们申请的业务日期，或某些人的出生日期

通常我将其存储为日期（在Oracle中），时间为0:0:0。如果我的应用程序的所有组件都在同一时区中，这将很好地工作。因为在DB中的日期是指dB时区的0:0:0，如果我将数据提交给另一个时区的用户，那么它很容易会有问题，因为例如2012-12250:0:0伦敦时间的日期实际上是2012-1224-16:0:0香港时间。p> 我想了两种解决方法，但都有不足之处

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

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

---

处理日期的建议方法是什么？或者大多数人只是使用上述三种方法中的一种（包括假设为同一时区）吗？

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

应该清楚的是，不可能将一个时区的日期转换为另一个时区的日期，因为它们代表不同的时间间隔。（大多数情况下，相邻时区可能会有例外，一个在夏令时，另一个不在夏令时。）出于同样的原因，不同时区之间的日期计算也不能正常进行。有时没有足够的数据来获取完美的答案

---

但是，你所问问题背后的问题的完整答案取决于日期的含义。例如，如果它们是诸如截止日期之类的法定日期，那么这些日期通常是根据办公楼的位置来确定的，比如说，截止日期是在什么地方。在这种情况下，日边界遵循一个时区，因此没有必要对其进行冗余存储。存储时间时，时间将转换为该时区的日期。

使用UTC everywhere使事情变得简单且一致。将日期（作为时间点）保存为数据库中的UTC，在UTC中对其进行计算，仅在视图层中显式转换为本地时间，将用户输入日期转换为UTC将为您需要的任何操作或计算提供相当稳定的基础。您实际上不需要以UTC向用户显示日期-实际以当地时间显示日期，并暗示您可以显示日期UTC会提供更多有用的信息。
如果您只需要保留日期（如生日，您在评论中提到的日期），请明确删除此类信息（如在DB级别上从DateTime到日期的转换，或任何代码级别的可能性）。
这是一个很好的规范化示例，与在代码页上使用UTF或在物理计算中保持相同的单位时所做的相同。

---

使用这种方法，不同日期的代码将简单得多。在显示UTC和本地人之间的日期和转换的情况下，许多框架（甚至语言本身）为您提供了处理本地人的工具，同时使用UTC等。

我曾经设计并领导构建一个实时交易系统，该系统可在多个时区处理客户，但是所有的发票都是在一个时区的时间段内开具的

对我来说，行之有效的解决方案是在每条记录上同时存储UTC时间和本地时间。这是在使用该系统几年后，意识到日期列实际上有两种不同的用途，因此数据是以这种方式存储的

虽然它在磁盘上占用了更多的字节（大不了——磁盘很便宜），但它使查询变得非常简单；“非正式”查询（例如，服务台使用本地时间列搜索客户交易）和“正式”查询（例如，会计部门发票批量运行使用UTC列）

---

它还处理了当地时间的问题，即每当夏时制倒退一小时时，“重新体验”一小时的交易，如果你是一个24小时的企业，那么只使用当地时间会是一个真正的痛苦。

事实上，我并不是说日期是一个特定的时间点。相反，正如我所提到的，这更像是一个“合乎逻辑的”日期。例如，在股票交易系统中，我可能有一个“业务日期”。即使我在2012-12-01 12:34:56下订单，我可能在2012-11-30的日期仍在做生意。另一个例子是生日，我们也很少考虑时区。例如，我的生日是1999-9-9，无论系统位于何处，我的生日仍然是1999-9-9，如果我从中国搬到美国，它不会变成1999-9-8 12:00pm。（如果我在做生日提醒，情况就不同了：P）正如我前面提到的，没有一个合理的日期；这取决于应用程序。正如您所提到的，生日使用的约定是，逻辑日期相对于出生的时区。正如我提到的，截止日期与归档办公室有关。如果您的目标是创建一个通用库，请使用我上面的建议。如果您有特定的应用程序