我在其他项目中也遇到过这个问题，但是现在我们正在Django / Python中使用Vue.js和PostgreSQL。
我们模型中的每个“日期”字段几乎都是真正的日期，而不是日期时间。业务用户不在乎时间，实际上存储任何这样的值都是令人误解的。一个很好的例子是税率的生效日期。从用户的角度来看，它在指定日期的午夜生效。
如果我们将其存储为Django DateTimeField或DateField，则需要时间。可能是0000h，但该值对业务没有意义，因为他们永远不需要在时间范围内查看或比较任何内容。如果我们要存储真实的日期时间，将其作为UTC放入数据库中，然后通过自动时区转换以本地时间显示给用户，则Django功能非常有用。但是我们没有。如果生效日期为2019年3月1日，则无论用户的时区如何，都应这样显示。如果日期存储为日期时间（2019、3、1、0、0、0）并由温哥华的某人输入，则该日期将作为多伦多另一用户的下一个日历日。绝对不是我们想要的。我们可以通过将时间部分设置为1200h来混淆它，但是真的吗？
在使用SQL或直接访问架构的工具（例如BI工具）时，根据数据库中的内部表示，我们还存在潜在的问题。我们如何知道哪个时区适用于datetime值？
因此，我们正在考虑使用ISO 8601格式（YYYY-MM-DD）的Django CharField。它将正确排序，可以轻松进行比较（或直接在SQL等某些工具中进行比较），并且如果客户端愿意使用该标准，则可以不重新格式化就显示它。如果需要进行日期算术，则可以使用Python标准库的datetime和calendar从/到字符串转换。无论如何，我们将需要使用它们来捕获SQL注入攻击。
我们还需要通过Datepicker处理日期输入，在存储之前将其转换为ISO 8601字符串，并在显示以进行编辑时再次返回。
这似乎是表达业务需求的一种更好的方法，并且摆脱了任何时区转换问题。
在日期时间和时区处理方面肯定有很多评论，但是我还没有发现有人采用这种方法来存储真实日期。我是否错过了重要的“陷阱”？我们在该项目中还很早就可以采用任何一种方式，所以我希望在重构成为一项繁重的工作之前确认这一点是否可行。