问题描述
我觉得我正在绕着这个房子转。
总而言之，我有一个位置模型，它有营业时间，在数据库中建模为 opens_at 和 closes_at。
所有时间都以 UTC 格式存储在数据库中。
如果我在纽约创建一个位置，在我的表单中将 opens_at 设置为 08:30，并将它作为 UTC 时间 08:30 保存到数据库中，为什么我需要担心时区？我不想以当地时间显示时间，因为用户会看到 03:30 的营业时间。
我是不是想多了？如果我有多个国家/地区的用户同时参加同一活动，我是否只需要担心时区？
因为这是关于物理位置的，所以我觉得不需要。
解决方法
是的，我确实遇到过这种情况。如果用户只想查看本地时区的时间，那么实际上没有必要将时区保存为 UTC。您可以在没有时区的本地时间保存它。
参考：Postgres Time without Time Zone
有些开发者会说你应该把它保存在 UTC 和时区，但我可以看到两个反对它的论据：
- 如果你现在不需要它，你可能永远不需要它。
- 您现在可能无法访问时区，或者可能需要额外的代码/复杂性来实施和验证。
- 如果您知道时区或纬度/经度或地址，您可以稍后再添加。
如果我在纽约创建一个位置，在我的表单中将 opens_at 设置为 08:30，并将它作为 UTC 时间 08:30 保存到数据库中，为什么我需要担心时区？
因为纽约的 08:30 不是 08:30 UTC。甚至所有日期的时间都不相同。
- 当纽约遵守东部标准时间（EST，UTC-5）时，现在是 13:30 UTC
- 纽约采用东部夏令时间（EDT，UTC-4）时是 12:30 UTC
因此，如果该位置每天在同一时间营业，那么您必须将其存储在当地时间。否则，您将在下一次 DST 转换后以一种或另一种方式离开一个小时。
即使对于不使用 DST 的时区，甚至对于非经常性事件，这也可能是一个问题，因为世界各国政府控制其境内的时区。他们可以更改是开始观察 DST 还是停止观察 DST、发生 DST 转换的日期和时间，或者它们与 UTC 的标准偏移量。有些人在进行此类更改时会给予足够的通知，而其他人则不会。在您最初记录事件和事件发生之间，给定的时区可能改变其行为总是有一些非零的机会。如果您使用本地时间记录，您需要做的就是更新系统上的时区数据（这通常会自动发生）。但是，如果您使用 UTC 记录事件，则在进行此类更改后转换返回时可能会关闭。
一般来说，未来事件应该总是按照描述事件的方式存储——这几乎总是在某个特定时区的本地时间。将 IANA time zone ID（例如 "America/New_York"）与位置或事件一起存储，以便您可以在需要时进行转换，但过早地转换为 UTC 可能会导致忽略原始信息。
为过去或当前事件（例如为交易添加时间戳）保留“始终为 UTC”的心态。