在 DxScheduler 中处理时区

Question

DxScheduler 是 DevExpress Blazor 控件，用于提供复杂的日历 UI。但下面的问题是关于日历中时区的 DB 到 UI 表示的问题。

以下的做法有没有问题。一个很大的限制是 DevExpress 确实支持约会集合的时区。它不支持每个约会的时区。 （可以做到，但这是工作。）

首先，我决定不跟踪每个约会的时区。这是可以做到的，但对我来说这是很多额外的工作。这不仅仅是时间问题，还意味着更多的错误。 （一位我非常尊敬的开发人员说，每一个

if

语句都是一个等待发生的错误。）此外，对于我 99% 的用户来说，他们关于我的应用程序的世界将在他们的时区中。

其次，这个应用程序将被美国各地以及世界各地的少数人大量使用。人们希望在当地时区查看他们的约会。

第三，在“本地”时间保存所有内容是危险的。对于大多数用途，它都会起作用，但对于不起作用的情况 - 我完蛋了。因为这样就无法了解 3:00 的会议位于哪个时区。

所以我正在做以下事情。

1. 所有约会均以 UTC 时间存储在数据库中。
2. 每个用户在注册时都会设置他们的时区。
3. 填充 UI 时，我读出约会并将其转换为用户的时区。
4. 调度程序的时区设置为用户的时区。

这种方法有什么问题吗？

注意：根据 StackOverflow 指南，我并不是在征求有关最佳方法的意见。我想问一下这种方法是否有问题。

Answer 1

您表示：

...我决定不跟踪每个约会的时区。 ...所有约会都以 UTC 时间存储在数据库中。

这是您的方法的主要问题。虽然它看起来可以避免错误，但它实际上引入了一个非常现实的问题，在时区更新的情况下可能会导致约会推迟一个小时。

重要的是要了解世界各国政府都会以他们认为合适的方式更新其时区。这可以是对夏令时适用性或开始/结束日期的更改，也可以是对标准时区偏移的更改。 （有时，时区适用的地理边界也可能会发生变化 - 但这比其他类型的变化更难以在软件中跟踪。）当发生此类变化时，有时会有足够的变化通知，有时没有。但出于争论的目的，我们假设您确实有足够的更改通知来使您的系统保持最新状态。

使用基于 UTC 的模型，如果在首次记录预约与生效之间的期间进行此类更改，则会出现此问题。这是一个示例场景：

• 2022 年 9 月左右的某个时间，用户预约了 2023 年 5 月 1 日上午 10:00。用户位于墨西哥城。
• 您的软件会查找时区偏移并识别出墨西哥城使用 UTC-6，但 4 月至 10 月之间的夏令时采用 UTC-5。因此，它使用 UTC-5 进行此约会，将

  2023-05-01T10:00-05:00

  转换为

  2023-05-01T15:00Z

  ，将该 UTC 时间存储在数据库中。
• 2022年10月，墨西哥政府废除了包括墨西哥城在内的墨西哥大部分地区的夏令时。您可以在这里阅读相关内容。这些更改在 IANA TZ 数据库2022f 版本中生效。
• 您的系统通过操作系统更新或平台/框架/语言/库更新接收时区更新。这很好，因为我们不想使用过时的数据来进行时区转换。
• 五月来临，那个约会也到了。由于墨西哥城不再适用 DST，因此 UTC-6 生效。您的软件将从数据库检索到的

  2023-05-01T15:00Z

  转换为

  2023-05-01T09:00-06:00

  。
• 用户原本希望预约上午 10:00，但您的软件却给了他们上午 9:00 的预约。他们在 10:00 出现，错过了预约时间。

为避免此问题，请牢记以下原则：

• 因为人们无法知道未来，所以“始终使用 UTC”建议仅适用于过去或现在的事件。
• 未来的事件应按照该事件适用的时区存储。
• 在大多数情况下，适用的时区标识符（例如：

  America/Mexico_City

  ）应与事件本身一起存储，或者与属于事件物理位置的关联记录一起存储，例如拥有多个办事处的企业等。但是，某些场景可能基于可变的本地时区，例如用户智能手机上的闹钟。