您可能想借鉴我在一个电子商务项目中实现的代金券开始/结束日期的想法，我正在开发这个项目：
另一个例子，展示了灵活性以及我们如何避免在用户界面中出现日期范围的歧义：
技术细节： 在我们的应用程序中，我们始终将日期存储为“带时区的戳”（postgres），因此没有任何数据库设置或连接设置会影响实际存储的时间戳。尽管 Postgres 不推荐这样做，但我们还是这样做了，因为它在任何情况下和任何 SQL 查询中都能 100% 保证日期的正确性。您可以使用 Postgres 的日期/时间/时区函数直接在 Postgres 中操作日期时区，并确信它始终 100% 正确。我们依赖它。
然后，我们为所有需要它的实体设置了时区：用户配置文件、市场、代金券、会计报告等——这样我们就可以毫不犹豫地即时将任何日期转换为任何时区。
这里的主要收获是：
- 始终以带时区的格式存储日期和时间。
- 始终存储时区偏好。
- 在用户界面中明确日期，不要搞什么“魔法”。
- 让用户在点击“保存”之前看到所选时区的实际日期。