当谈到夏令时时，我很难理解Rails的时区支持。
我将所有数据库时间存储在UTC中。存储用户时区，以便它们直接映射回ActiveSupport::TimeZone值（即Central Time (US & Canada)）。
我想完全忽略夏令时。如果事件从5:30pm开始，则无论夏令时是否生效，它始终从5:30pm开始。
考虑到所有时间都是统一存储的，是否可以检索数据库时间并在本地显示，从而完全忽略夏令时？我忽视夏令时会遇到什么问题吗？
我不想听起来迂腐，但。。。
我想完全忽略夏令时。
好吧，那你就一个人了。尽管我们抱有最大的希望和愿望，但现实世界中的大部分人都使用夏令时。你可以在这里快速入门。
如果活动在下午5:30开始，那么无论夏令时是否生效，活动都会在下午5:50开始。
5:30给谁？如果你说的是协调世界时5:30，那当然。但如果你说的是美国中部时间5:30，那么你必须考虑夏令时。否则，一年中有一半的时间人们会在他们认为的5:30和你认为的6:30出现在你的活动中。
考虑到所有时间都是统一存储的，是否可以检索数据库时间并在本地显示，从而完全忽略夏令时？
您将时间存储在UTC中，这很好。当您在本地显示它们时，您应该而不是忽略DST。
我忽视夏令时会遇到什么问题吗？
是的，人们通常不理解这一点。通常情况下，如果你指的是当地时间，那么你的意思是他们的当地时间。如果你不把夏令时包括在计算中，那么你会对你谈论的时间产生分歧。
另一个建议是，您可能需要考虑使用TZInfo gem而不是ActiveSupport::TimeZone。然后，您将使用IANA标识符（如America/Chicago）存储时区选择。这些在Rails之外是可以识别的。
出于某种无法解释的原因，ActiveSupport人员认为他们应该将时区限制在他们认为"有意义"的146个值内。但他们没有解释他们的过程，他们似乎也没有做好维护工作。我问过为什么，但没有得到太多详细的回复。
您还可以查看时区标记wiki。
Rails将把您的日期/时间转换为应用程序配置的时区或用户时区（假设您已经设置了某种过滤器来使用user.timezone）；这将包括基于DST的操作。
您需要覆盖此行为，并且可能有几个选项：
- 考虑使用Time.dst？以便为从数据库中提取的内容减去/添加时间
- 考虑在AR中使用skip_time_zone_conversion_for_attributes，并通过虚拟属性自己进行转换
- 将时间存储为日期/时间以外的其他内容；可能是一个独立于日期的字段，只是一个普通的字符串格式