我意识到这是一个常见的问题，但我找不到任何帖子指出使用/存储用户时区偏移量的缺点。这不是更好、更有效的方法吗？
长长的时区下拉列表对用户来说并不友好，而且大多数这样的列表并没有包含所有的城市。它们还要求用户指定自己的时区。我觉得简单地检测它可能要好得多。在我的情况下，我的应用程序是一个带有Reach前端的ASP.NET Core应用程序，通过JavaScript捕获用户的时区偏移量非常容易。
为什么存储用户时区的偏移量不是一个好主意？
为什么存储用户时区的偏移量不是一个好主意？
是。许多的时区和偏移量不是一回事。时区表示本地时间所在的地理区域。一个时区与UTC的偏移量可能会发生几种不同的变化。其中一些是有规律的(如夏令时)，另一些是不规则的(如政府更改标准时间或dst规则)。
。。。在我的情况下，我只想显示用户当前时区中的所有日期时间值，以便它们对用户有意义。
好的，假设您检查用户的当前时区偏移量，它是UTC-7。因此，你将其应用于申请中的某些日期和时间，并完成了——你是这么想的。除了你没有考虑到用户在加利福尼亚州，而且你的一个日期是12月，当时偏移量应该是UTC-8。
所以你试着纠正这一点，并制定出"当我看到-7时，有时可能是-8"的规则。除了现在你有一个用户出现在科罗拉多州，那里的冬天是-7，夏天是-6。或者另一位来自亚利桑那州的用户，该州大部分地区全年处于-7。你怎么知道该遵守哪一套规则？如果不引用实际的时区，则无法执行此操作。
这在世界范围内变得更加复杂。例如，UTC+2的变化数量简直太疯狂了。即使是在UTC+2和UTC+3之间切换的国家，它们也不会在同一天的同一日期或同一时间切换！
另请参阅：时间问题&时区-电脑爱好者(YouTube)以及StackOverflowtimezone标签wiki。