时区和本地化 [英] Time zones and Localisation

查看:118
本文介绍了时区和本地化的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在UTC存储所有时间,以便在我开始使多个站点和服务器联机时更容易。

I'm currently storing all times in UTC, to make things easier for when I start bringing multiple sites and servers online.

当翻译 date datetime 时,对象进入我的模板中的字符串和接受用户输入。下午6:00 UTC并不意味着太多的人在PST。同样,要求用户输入UTC时间是要求灾难。

The problem comes in when translating date and datetime objects into strings in my templates and when accepting user input. 6:00PM UTC doesn't mean a whole lot to someone who is in PST. Likewise, asking users to input times in UTC is asking for disaster.

如何以智能,不容易出错的方式正确翻译这些值?有没有办法可以从HTTP请求中确定用户所在的时区?我真的需要一种方法来尽可能少的努力来确定用户的时区。

How can I correctly translate these values in a smart, not-error-prone way? Is there a way I can determine from the HTTP request what timezone a user is in? I really need a way to determine the user's timezone with as little effort as possible.

推荐答案

依靠客户端自我报告他们的时区的问题是,总是有机会(有机会有多大可辩论),你将真正获得的是一个UTC偏移量。如果您获得UTC偏移量,则您的逻辑大部分时间都能正常工作,但实际上仅适用于客户端生成的确切时间戳。任何过去或将来的时间可能都有不同的UTC偏移量,如果没有适当的时区数据库,则无法预测。在夏令时边界附近,使用UTC偏移可能会产生灾难性的错误结果。

The problem with relying on the client to self-report their time zone is that there is always a chance (how big of a chance is debateable) that what you will really get is a UTC offset. If you get a UTC offset, your logic will work fine most of the time, but in reality will only apply to the exact timestamps produced by the client. Any past or future times may have a different UTC offset, and that can't be predicted without a proper time zone database. Near the daylight savings boundary, using UTC offsets can produce catastrophically wrong results.

除此之外,一些非识字用户(即祖母)可能不知道如何设置当地制度时区;或者隧道式会话或虚拟机上的用户可能有一个本地时区,并没有为其实际偏好设置。

Even besides that, some non-literate users (i.e. grandma) may not know how to set the time zone of their local system; or users on tunnelled sessions or virtual machines may have a "local" time zone that is not set for their actual preference.

根据客户端的政治时区您对该客户端(IP等)的了解可能是错误的,如果用户无法覆盖猜测,可能会令人烦恼。但是对于匿名用户或新用户注册,只要您给予用户一些更改方式(如果出错),使用这种方法就可以看出没有错误。

Guessing the political time zone of the client based on what you know about that client (IP, etc) can be wrong, and can be quite annoying if there is no way for the user to override the guess. But for anonymous users or new user sign-up I see nothing wrong with using such a method as an initial guess, as long as you give the user some way to change it if it's wrong.

我的建议是具体的:


  • 将Olson时区作为任何用户配置文件的一部分。时区可以按国家查询,这样可以让用户选择时区相对无痛。给0.01%的用户关心直选UTC的选择: - )

  • 如果您使用基于IP的猜测填充用户配置文件中的默认值,那么您将如果您使用良好的查找服务,大部分时间是正确的。但是如果错误,请允许用户更改。

  • 对于匿名用户,在显示或输入本地时间的任何页面上提供某种小部件,这样可以选择其Olson时区,以与用户简档相同的方式。将他们选择的值存储在cookie中。默认为UTC或上述的猜测值。

在实施基于Web的应用程序之前需要在本地化时间显示时间戳,我发现并不是所有的客户端在过去和将来的日期正确地翻译UTC到本地时间。我不得不在服务器端执行所有转换。这可能需要一个需要本地时间和Olson时区并返回UTC时间的Web服务。

In implementing a web-based application previously that needed to display timestamps in localized times, I found that not all clients translate UTC to local times correctly for past and future dates. I had to perform all conversions on the server side. This may necessitate a web service that takes a local time and an Olson time zone and returns a UTC time.

这篇关于时区和本地化的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆