我目前正在向网站添加类似不在办公室的系统，用户可以在其中标记他们不在办公室的日期和时间，以便他们可以提供其他用户的信息以在他们外出时用作备份。
我遇到的问题是将用户的本地时间转换为 UTC。我已经看到其他帖子通过向用户提供 UTC 并让客户端 (js) 将时间转换为本地时间和从本地时间转换来解决此问题。但是，我确实可以访问一个专有系统，我可以使用它来根据用户的时区偏好在服务器端转换日期。
我的问题是：我是否应该使用服务器端转换，这将允许提供用户的 home 本地时间（例如，他们的美国时间，无论他们在哪里登录），还是应该使用客户端转换？
有人有这方面的经验吗？每种方法有哪些不太明显的优点/缺点？
【问题讨论】：
标签： date localization time utc
以 UTC 存储所有内容是一个非常好的主意，我建议您坚持下去。
您可以使用的方法很少。我假设您将拥有用户的个人资料。您可以决定让用户能够选择他们喜欢的时区并使用此信息显示所有内容。以及适当处理所有用户输入（在服务器端转换，假设时区是首选）。
处理它的另一种方法是通过Date.getTimeZoneOffset() 实际获取用户的时区偏移量并以某种方式将其发送到您的服务器（即通过隐藏的表单字段或 Ajax）。当您知道这一点时，在用户时间显示所有内容将是小菜一碟。在这种情况下，您可能希望在客户端转换日期/时间并将其作为 UTC 发送（或使用带有时区偏移的隐藏表单字段）。
在这两种情况下，您都在服务器端处理数据库日期转换。根据我的经验，这是最好的方法。我想指出，除了转换时区之外，您可能应该考虑以正确的格式显示日期/时间（即取决于 AcceptLanguage 标头值）。
【讨论】：
问题归结为您是否认为用户会在他们的个人资料中设置正确的时间，以及您是否认为他们的客户端设置为他们计算机设置的时区。
如果家庭时间设置在配置文件中是可选的（大量用户不会正确设置的），那么您应该使用客户端时间。
如果您希望很多用户从未设置为首选时区的计算机访问系统（例如，如果他们从酒店计算机访问系统），那么您应该在服务器上进行时间转换。
如果这两个都适用于你，你会被诅咒，如果你不这样做会被诅咒。
如果两者都不适用，那么两种解决方案都将提供相同且令人满意的结果。
无论您选择什么，最好在显示时间时添加时间戳以消除任何混淆。
【讨论】：