use*_*872 4 timezone datetime localization utc timezone-offset
我有来自多个时区的用户，并以 UTC 格式将时间存储在数据库中。单独遇到时间部分的问题。
按如下方式存储用户本周的工作时间。
| ID | 用户身份 | 天 | 时间 | 时间结束 |
|---|---|---|---|---|
| 1 | 1 | 0 | 10:00 | 18:00 |
| 2 | 1 | 1 | 10:00 | 18:00 |
| 3 | 1 | 2 | 10:00 | 18:00 |
| 4 | 1 | 3 | 10:00 | 18:00 |
| 5 | 1 | 4 | 10:00 | 18:00 |
日，0 表示星期日，1 表示星期一，...
此处，时间以 UTC 格式存储。UI 中的时间将根据浏览器时区进行转换。由于这里不需要日期部分，因此它在这里引起了问题。
例如，假设用户在 UI 中选择上午 7 点到下午 7 点，时间将转换为 UTC，即今天 15:00 到明天 02:00。因此，在数据库中，时间存储为
| ID | 用户身份 | 天 | 时间 | 时间结束 |
|---|---|---|---|---|
| 1 | 1 | 0 | 15:00 | 02:00 |
| 2 | 1 | 1 | 15:00 | 02:00 |
| 3 | 1 | 2 | 15:00 | 02:00 |
| 4 | 1 | 3 | 15:00 | 02:00 |
| 5 | 1 | 4 | 15:00 | 02:00 |
这里，开始时间大于结束时间，这是不正确的。
当只存储时间部分时，我们需要如何处理时区？
我的要求是根据以下信息为用户获取空位。
已预订插槽，
| ID | 用户身份 | St_time（日期时间） | 持续时间（分钟） |
|---|---|---|---|
| 1 | 1 | 2021-11-27 16:00:00 | 30 |
| 1 | 1 | 2021-11-27 18:00:00 | 45 |
这里的时间是 UTC 时间。
| ID | 用户身份 | 时间 | 结束日期 | 时间 | 时间结束 |
|---|---|---|---|---|---|
| 1 | 1 | 2021-11-22 | 2021-11-25 | 09:00 | 18:00 |
| 1 | 1 | 2021-12-17 | 2021-12-20 | 09:00 | 18:00 |
此处时间也需要以 UTC 格式存储
| ID | 用户身份 | 天 | 时间 | 时间结束 |
|---|---|---|---|---|
| 1 | 1 | 0 | 15:00 | 02:00 |
| 2 | 1 | 1 | 15:00 | 02:00 |
| 3 | 1 | 2 | 15:00 | 02:00 |
| 4 | 1 | 3 | 15:00 | 02:00 |
| 5 | 1 | 4 | 15:00 | 02:00 |
我需要根据上述 3 个信息计算空缺插槽。但是，当我们将时间部分存储在 UTC 中时，时间部分会令人困惑。处理这个问题的最佳方法是什么？
小智 5
避免午夜环绕的一种方法是将工作时间存储为具有开始时间和持续时间，而不是开始时间和结束时间，就像您对预订时段所做的那样。您可以对阻塞的插槽执行相同的操作，以便为所有事件提供良好的一致存储模型。
\n我还建议将工作时间存储在 user\xe2\x80\x99s 本地时间中，以及指示工作位置的IANA 时区字符串。以 UTC 存储的问题是，某些时区全年都会进入和退出夏令时。假设\xe2\x80\x99s 说我\xe2\x80\x99m 在纽约市，我希望我的工作时间是纽约时间09:00 到17:00。由于目前纽约是东部标准时间 (UTC-5)，因此将转换为 14:00 至 22:00。一旦夏天到来，纽约就会进入东部夏令时间（UTC-4），所以我的工作时间就会突然变成纽约时间10:00到18:00。
\n您还可以将时区与用户信息一起存储，以便工作时间与时区无关。这将允许您在用户所在的任何时区中指定类似 \xe2\x80\x9c09:00 到 17:00 的内容。\xe2\x80\x9d
\n每当您处理重复发生的事件时，我总是发现将它们存储在事件发生的时区中会更清晰，因为从 UTC 转换的逻辑全年都会变化。对于绝对事件，例如预订和阻塞的时段，将它们保留在 UTC 中仍然有意义，因为它们指的是一个特定的时间事件。
\n| 归档时间： |
|
| 查看次数： |
858 次 |
| 最近记录： |