问ISO 8601字符串，而不是日期时间

EN

我在其他项目中遇到过这个问题，但现在我们正在使用Django / Python和Vue.js和PostgreSQL。

在我们的模型中，几乎每个' date‘字段都是一个真正的日期，而不是日期时间。业务用户并不关心时间段，事实上，存储任何这样的值都是误导的。税率的生效日期就是一个很好的例子。从用户的角度来看，它在指定日期的午夜生效。

如果我们将其存储为Django DateTimeField或DateField，它需要一个时间部分。它可以是0000h，但它的值对业务没有意义，因为他们永远不需要查看或比较任何与时间部分的内容。如果我们想要存储一个真实的日期时间，将其作为UTC放入数据库中，然后通过自动时区转换以当地时间显示给用户，那么Django功能是非常棒的。但我们没有。如果生效日期是2019年3月1日，则无论用户所在的时区如何，都应该显示生效日期。如果日期存储为日期时间(2019，3，1，0，0，0)并由温哥华的某个用户输入，则对于多伦多的另一个用户来说，它将显示为下一个日历日。这绝对不是我们想要的。我们可以通过将time-part设置为1200h来拼凑它，但是真的吗？

在使用SQL或直接访问模式的工具(例如BI工具)时，我们也会遇到潜在的问题，这取决于数据库中的内部表示。我们如何知道哪个时区适用于DateTime值？

因此，我们正在考虑使用ISO8601格式(YYYY-MM-DD)的Django CharField。它将正确排序，可以很容易地进行比较(或直接在一些工具中，如SQL)，并且如果客户愿意使用该标准，则无需重新格式化即可显示。如果我们需要进行日期运算，我们可以使用Python标准库datetime和calendar来进行字符串转换。无论如何，我们都需要使用它们来捕获SQL注入攻击。

我们还需要通过Datepicker处理日期输入，在存储之前转换为ISO 8601字符串，并在显示进行编辑时再次转换回来。

它似乎是表示业务需求的一种更好的方式，而且它消除了任何时区转换问题。

当然有很多关于日期时间和时区处理的评论，但我还没有发现有人使用这种方法来存储真实的日期。我是不是漏掉了一个重要的“问题”？我们在这个项目中已经足够早了，我们可以选择任何一种方式，所以我希望在重构成为一项大任务之前确认这将会起作用。