在夏令时方面，我无法理解Rails的时区支持。
我将所有数据库时间存储在 UTC 中。存储用户时区，以便它们直接映射回ActiveSupport::TimeZone值（即Central Time (US & Canada)）。
我想完全忽略夏令时。如果某个活动从5:30pm开始，则始终从5:30pm开始，无论夏令时是否生效。
考虑到所有时间是否统一存储，是否有可能检索数据库时间并在本地显示它们以便完全忽略夏令时？是否有任何问题我会忽视夏令时？
答案 0 :(得分：5)
我并不是说听起来很迂腐，但是......
我想完全忽略夏令时。
那么，你会独自一人。尽管我们有最大的希望和愿望，但现实世界中的大部分都使用夏令时。 You can get a quick primer here
5:30为谁？如果你说5:30 UTC，那么肯定。但如果您在美国中部时间说5:30，那么您必须考虑DST。否则，一年中半数人会出现在他们认为是5:30的活动中，你认为是6:30。如果活动在下午5:30开始，则始终在下午5:30开始，无论夏令时是否生效。
考虑到所有时间是否统一存储，是否有可能检索数据库时间并在本地显示它们以便完全忽略夏令时？
您将时间存储在UTC中，这很好。当您在本地显示它们时，您应该不忽略DST。
我是否会遇到任何问题而忽略夏令时？
是的，人们通常不了解这一点。一般来说，如果您参考当地时间，那么您的意思是他们的本地时间。如果你没有在计算中包含DST，那么你会对你所谈论的时间产生分歧。
另一个建议，您可能需要考虑使用TZInfo gem而不是ActiveSupport::TimeZone。然后，您将使用IANA标识符（例如America/Chicago）存储时区选择。这些在Rails之外是可识别的。
由于某些无法解释的原因，ActiveSupport人员认为他们应该将时区限制为他们认为“有意义”的146个值。但是他们没有解释他们的过程，他们似乎没有在维护之上。 I've asked why，但没有得到太多详细的回应。
您可能还希望查看the timezone tag wiki。
答案 1 :(得分：1)
Rails会将您的日期/时间转换为应用程序配置的时区或用户时区（假设您已设置某种过滤器以使用user.timezone）;这将包括基于DST的操纵。
您需要覆盖此行为，可能有几个选项：