时区与偏移量存储用户时区：TimeZone vs Offset

Question

时区与偏移量存储用户时区：TimeZone vs Offset

javascriptasp.netreactjstimezonetimezone-offset

7

我知道这是一个常见的问题，但我找不到任何帖子指出使用/存储用户时区偏移量的缺点。这难道不是更好也更有效的方法吗？

时间区域的长下拉列表不太友好，大多数这样的列表也没有所有城市。他们还需要用户指定其时区。我觉得简单地检测它可能会更好。在我的情况下，我的应用程序是一个具有React前端的ASP.NET Core应用程序，通过JavaScript很容易捕获用户的时区偏移量。

为什么存储用户时区的偏移量不是个好主意呢？

- Sam

2

时区和偏移量不是同一回事。同一个偏移量可以被多个时区使用，同一个时区在历史上可能有多个偏移量，这是由于夏令时（或者仅仅是因为他们决定改变偏移量）。由于这是N对N的关系，仅存储偏移量将给您提供提示（可能区域的列表），但不是确切的区域。 - user7605325

公正的观点。我认为最终答案取决于个人的需求。在我的情况下，我只想以用户当前的时区显示所有日期时间值，以便它们对用户有意义。这包括用户离开自己的家庭时区但仍在使用我的应用程序的那些时间。我觉得检测偏移变化并自动以用户当前的时区显示所有日期/时间值非常用户友好。不过，在检测到更改时显示通知可能是一个好主意。 - Sam

在这种情况下，您可以将所有内容存储为UTC，并在显示时转换为用户的时区。 - user7605325

没错。目前我将所有的日期/时间值存储在UTC中，并且也存储了用户的时区。但是越来越多的时候，我感觉我不需要用户的时区。我所需要的只是转换的偏移量。 - Sam

2

实际上，时区是一个地区在历史上（包括夏令时更改）具有、现在拥有和将来会拥有的所有偏移量的集合，因此只有使用时区才能获取每个UTC瞬间的正确偏移量。 - user7605325

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Matt Johnson-Pint · Accepted Answer

有什么理由不建议存储用户时区偏移量吗？

有很多。时区和偏移量并不相同。时区表示一个本地时间对齐的地理区域。时区可能会在其与UTC的偏移量上进行几个不同的更改，其中一些是定期的（如夏令时），而另一些是不规则的（例如政府更改其标准时间或夏令时规则）。

在我的情况下，我只想以用户当前的时区显示所有日期时间值，以便它们对用户有意义。

好的，假设您检查用户当前的时区偏移量为UTC-7。因此，您将其应用于应用程序中的某些日期和时间，然后完成 - 所以您认为。除了您没有考虑到用户在加利福尼亚州，并且您的某些日期在12月份，当时偏移应该是UTC-8。

因此，您尝试进行纠正，并计算出“当我看到-7时，有时可能是-8的规则”。除非引用实际的时区，否则无法完成。

这在全球范围内变得更加复杂。例如，UTC + 2的变化数量就很疯狂。即使对于在UTC + 2和UTC + 3之间切换的国家 - 它们并不总是在同一天或同一时间切换！

请参见：时区问题与计算机科学（YouTube）和StackOverflow的时区标签wiki。