我知道这个问题已被问过几次，但我认为我对它的一个略微不同的方面感兴趣。
我的网站有两种用户。让我们称他们为前端（FE）用户和后端（BE）用户。 FE用户未经身份验证（他们没有用户帐户，因此没有时区），但他们可以创建预订并选择特定的日期和时间。
BE用户拥有用户帐户。他们可以选择自己的时区。当他们查看预订时，它应该显示与FE用户输入的时间完全相同的时间。如果我将此时间转换为使用BE的时区，则时间会有所偏差。
其他日期时间，例如创建预订时，应转换为BE的时区。
例如，如果FE用户在下午5:00创建2014-03-11的预订，它将作为2014-03-11 5:00 pm UTC存储在数据库中。当BE用户查看它时，它将被拉出数据库，保留在UTC中并显示为下午5:00。
如果他们查看预订的创建时间，可能是在UTC时间下午2:00录制的，但是如果我向BE用户显示下午2:00他可能会感到困惑，因为它甚至可能在将来出现（如果UTC超过他当地的时区）！
所以，据我所知，解决这个问题的唯一方法就是要非常小心我将时区换成哪个日期，哪些日期单独留下，对吧？没有简单的方法可以解决这个问题，这样我可以在整个应用程序中使用一致的时区吗？
答案 0 :(得分：2)
......解决这个问题的唯一方法就是要非常小心我将时区转换成哪个日期，哪些日期单独留下，对吧？
总的来说，这是一个好主意。使用时间意味着理解您正在使用的上下文。如果您尝试只设置一次而忘记它，您可能至少有一部分应用程序行为不正确。
在您的特定用例中，您描述＆＃34;预订＆＃34;因为进入了一个未指定的时区。但是你说你将它们存储为UTC。如果预订真正与任何时区无关，那么您在使用UTC时不会引入UTC。只是不指定它们。 （如果您提供有关您的语言和数据库的详细信息，我可以推荐特定的数据类型。）
但是 - 可能存在您不考虑的背景。当您预订时，它是否适用于特定的位置？如果是，则可以考虑该位置的时区而不是用户的时区。您可以使用位置的时区转换为UTC，也可以存储＆＃34;日期 - 时间偏移＆＃34;归一化到位置时区的组合值。如果您需要，可以允许合理转换预订时间。只有您可以决定这是否对您的应用有意义。
关于录制的时间，这是一个不同的背景。它当然可以是UTC，然后只是转换到查看它的任何人的时区。
答案 1 :(得分：1)
有两种解决方案：
主要内容 - 始终在输出接近实际日期时间值
时指示时区