网站上从用户当地时间到 UTC 的日期/时间转换
我目前正在向网站添加一个类似外出的系统，用户可以在其中标记他们的外出日期和时间，以便他们可以提供其他用户的信息，以便在外出时用作备份。
我遇到的问题是将用户的本地时间转换为 UTC。我见过其他帖子通过向用户提供 UTC 并让客户端 (js) 将时间与本地时间相互转换来解决此问题。但是，我确实可以访问专有系统，我可以使用该系统根据用户的时区首选项在服务器端转换日期。
我的问题是：我是否应该使用服务器端转换，这将允许提供用户的家庭本地时间（例如，他们的美国时间，无论他们在哪里登录），或者我应该使用客户端转换？
有人有这方面的经验吗？每种方法有哪些不太明显的优点/缺点？
I'm currently adding an out of office like system to a website, where users will be able to mark their out of office dates and times such that they can provide another users's information to use as a backup while they are out.
The problem I have, is converting the users's local time to UTC. I've seen other posts that address this issue by supplying UTC to the user, and having the client (js) convert the time to and from local time. I do, however, have access to a propriety system I can use to convert the date server-side based on the user's time-zone preference.
My question is this: Should I use the server side conversion, which would allow a user's home local time to be supplied (say, their US time, regardless of where they are logged in), or should I use the client side conversion?
Does anyone have any experience with this? What are some of the less obvious advantages / disadvantages of each method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将所有内容存储在 UTC 中是一个非常好的主意，我建议您坚持这样做。
您可以使用的方法很少。我假设您有用户的个人资料。您可能决定让用户能够选择他们喜欢的时区并使用此信息显示所有内容。以及适当地处理所有用户输入（在服务器端进行转换，假设时区是首选）。
另一种处理方法是通过 Date.getTimeZoneOffset() 实际获取用户的时区偏移量，并以某种方式将其发送到您的服务器（即通过隐藏表单字段或 Ajax）。当您知道这一点时，在用户时间内显示所有内容将是小菜一碟。在这种情况下，您可能希望在客户端上转换日期/时间并将其作为 UTC 发送（或使用带有时区偏移的隐藏表单字段）。
在这两种情况下，您都在服务器端处理数据库日期转换。根据我的经验，这是最好的方法。我想指出，除了转换时区之外，您可能应该考虑以正确的格式显示日期/时间（即取决于 AcceptLanguage 标头值）。
Storing everything in UTC is a very good idea and I recommend that you stick to it.
There are few approaches you can use. I assume that you would have User's profiles. You may decide to give users an ability to pick the time zone they prefer and display everything using this information. As well as treat all user input appropriately (convert on server side, assuming the time zone is preferred one).
Another way to handle it, is to actually take User's time zone offset via
Date.getTimeZoneOffset()and send it out to your server somehow (i.e. via hidden form field or Ajax). When you know that, showing everything in User's time would be piece of cake. In this case you might want to convert date/time on the client and send it out as UTC (or use hidden form field with time zone offset).In both cases you handle database date conversion on server side. This is the best approach from my experience. I would like to point out, that apart from just converting time zones, you probably should think about displaying date/time in correct format (i.e. depending on AcceptLanguage header value).
问题归结为您是否认为用户会在其个人资料中设置正确的时间，以及您是否认为他们的客户端设置为其计算机设置的时区。
如果家庭时间设置是配置文件中的可选设置（大量用户没有正确设置的设置），那么您应该使用客户端时间。
如果您预计许多用户从未设置为首选时区的计算机访问系统（例如，如果他们从酒店计算机访问系统），那么您应该在服务器上转换时间。
如果这两种情况都适用于你，那么你做的话就很糟糕，不做也很糟糕。
如果两者都不适用，则两种解决方案都将提供相同且令人满意的结果。
无论您选择什么，最好在显示时间时添加时间戳以消除任何混乱。
The issue comes down to whether you think that users will set the correct time in their profile and whether you think that they have a client set to the timezone that their computer is set to.
If the home time setting is an optional one in the profile (one that a large number of users will not have set properly), then you should use the client side time.
If you expect a lot of users to be accessing the system from a computer not set to their preferred timezone (say if they are accessing it from a hotel computer), then you should do the convert the time on the server.
If both of these apply to you, are are damned if you do and damned if you don't.
If neither one applies than both solutions will provide equal, satisfactory results.
No matter what you choose, it is a good idea to add a time stamp to the time when you display it to clear up any confusion.