Javascript/PHP and timezones
I\'d like to be able to guess the user\'s timezone offset and whether or not daylight savings is being applied. Currently, the most definitive code that I\'ve found for this
-
I think that without knowing the exact timezone, There will always be a chance you miss out on some obscure rule.
As with most internationalization issues, there tend more obscure rules than you expect.I would however go for option A: "pick a likely timezone with the correct offset" exactly because timezone stuff tends to be more complicated than you would expect. especially when you take daylight saving changes into account. If you go for option A, you can use the standard functions provided by PHP.
You could combine this with other metrics to improve your quality of prediction; for example:
- Based on visitor statistics: pick the timezone where most visitors come from;
- Based on accept_headers: match the language to a timezone;
- based on IP-geolocation: match with country in correct timezone.
Combining the above should give a quite reasonable estimate. But 100% certainty cannot be achieved.
讨论(0) -
To robustly determine a user's timezone using javascript. Check out jsTimezoneDetect.
It will give you an Olsen timezone database key that you can use for server side datetime calculations.
讨论(0) -
If this is a poll, then "b" is my vote.
Firstly, all times should be stored in UTC. This is dogma. It's very sensible dogma, the kind about which you end up saying "I sure wish I had followed that," after your project gets more complicated. Among other things, it is the only unambiguous, consistent way to store all points in time. Any timezone with daylight savings time has ambiguous time references around the switch (1:30 am usually happens twice, for example). Also, when converting between timezones, most of the time you end up using UTC as an intermediary anyway.
Second of all, you have to decide whether your site is international or not. If not, then you make rules for the six U.S. time zones and end it. With three browsers reporting timestamps in their own whacky ways, that's still only 18 cases, and it should be possible to handle them. Anything beyond that, and you should assume that it requires an advanced degree to anticipate daylight savings time differences. The times switch on different days in different places.
Your biggest problem with b is that, if this is a calendar-like application, scheduling will still be an issue if you can't accurately determine what time zone someone is in. For example, suppose it's February. No one is on DST. Someone schedules something for 6pm (local) on May 5. You see the offset is UTC-4. How do you know whether that person is in New Brunswick, which observes DST (in which case the time meant is 2100 UTC), or Puerto Rico, which does not (in which case the time meant is 2200 UTC? It's a tricky question. This post may have some help.
讨论(0) -
If you want to rely on javascript you can simply send the utc time/timestamp back and forth and let the client convert it to its local time representation.
edit: simple self-contained example (using jquery)
<html> <head> <title>...</title> <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script> <script type="text/javascript"> function foo(){ $('.time').each( function() { var t = $(this); var d = new Date(Date.parse(t.text())); t.text(d.toLocaleString()); }); } </script> </head> <body> <div class="time"><?php echo gmdate(DateTime::RFC1123); ?></div> <button onclick="foo()">local time</button> </body> </html>If javascript is not available the user still sees a date/time though it's in UTC.
edit2: And there is a javascript library (or was it even a jquery plugin?) that does this kind of things plus some nifty conversions like "an hour ago", "last week" ..something like that. But I forgot the name :(讨论(0) -
Please see also this alternative: https://stackoverflow.com/a/12682439/1691517
Detects 90 timezones and has 100% accuracy in tested platforms.
讨论(0)
加载中...
- 热议问题