标签云

微信群

扫码加入我们

WeChat QR Code

Is there any standard way for a Web Server to be able to determine a user's timezone within a web page?

Perhaps from an HTTP header or part of the user-agent string?


Ask the user. If you get the time zone from the user's computer, and it is set wrong, then what?

2018年07月19日39分31秒

Then the user probably doesn't care?

2018年07月19日39分31秒

You might consider making John Isaacks's the correct answer... His solution is a lot simpler, to put it lightly.

2018年07月19日39分31秒

Do you mean stackoverflow.com/q/1091372/218196 ?

2018年07月20日39分31秒

No. Doesn't help my current cause, though looks useful for other things. What I need to do is take the getTimezoneOffset() minutes, and pass them to something from which will give me America/Los_Angeles for example. Or pass something to a function that will give me that or equivlent. Im not looking to display times based on the users set timezone more so than I am based on the place something took place..

2018年07月19日39分31秒

What about users who use cell phones that have browsers without javascript support? I like the question, the user asks about HTTP headers, user agent... is there a way to make this work server side, as accurate as possible?

2018年07月19日39分31秒

This doesn't account for Daylight Saving Time / Summer Time, but the link posted by Joseph Lust does: stackoverflow.com/a/5492192/462162

2018年07月19日39分31秒

This doesn't always work for DST. Get timezone offset does exactly what it says. It get's the offset. A time ZONE is actually a geographical area. This won't work for daylight savings since you don't know which hemisphere the user lives in, or if their country even has daylight savings. Why not use this instead: >>> date.toTimeString() "15:46:04 GMT+1200 (New Zealand Standard Time)"

2018年07月19日39分31秒

I beg to differ with Keyo. The definition of getTimezoneOffset() (according to the ECMA standard ecma-international.org/ecma-262/5.1/#sec-15.9.5.26) is "Returns the difference between local time and UTC time in minutes." - in other words, it should take daylight savings into account. Mozilla's documentation says "Daylight saving time prevents this value from being a constant even for a given locale."

2018年07月19日39分31秒

One thing to note here; some places (such as Newfoundland in Canada) have timezones that are off by half an hour, so after dividing by 60 your answer may not be an integer.

2018年07月19日39分31秒

What about when a user is downloading an .ics file that should have a start time specific to their location (e.g. 9-11am across the country)? They shouldn't HAVE to say what their time zone is imo.

2018年07月19日39分31秒

Ishmaeel: but users do travel internationally and they shouldnt need to tell their timezone each time they login from some non-native timezone

2018年07月19日39分31秒

This doesn't answer the question, which clearly implies he's looking for a technological solution.

2018年07月19日39分31秒

gWiz OP is asking for a standard solution. This is pretty standard.

2018年07月19日39分31秒

The best solution would probably be a combination of asking the user (e.g. providing a time-zone drop down at the top of a report), while defaulting the drop down selection to a GPS-determined time-zone when the user is on a mobile device that provides location information, and otherwise default to UTC.

2018年07月19日39分31秒

Strangely, this is the only correct answer to the question, which asks how to do it server side. I suspect the reason there are other answers with more votes is because once you realize you need to do it client side you end up using the other answers. But IMHO anyone upvoting another answer should be upvoting this one too.

2018年07月19日39分31秒

I believe the best method is to use geo-ip location to sort the possible time zones and by default pick the first one that is (close) match to user agent time offset (JavaScript required). Even after that, you have to provide a way to fix the timezone after even this method will select the incorrect one.

2018年07月19日39分31秒

MikkoRantalainen careful when using proxies through, as they don't always advertise themselves in the headers.

2018年07月19日39分31秒

Matthieu there exists a better answer nowadays: stackoverflow.com/a/11836123/334451

2018年07月19日39分31秒

I have voted this answer up because the latitude and longitude obtained from databases like GeoIP (which has a free version available as of now) can be combined with databases that convert such a coordinate to a time zone. I think GeoNames has a latter such database.

2018年07月19日39分31秒

See also this question.

2018年07月19日39分31秒

The current versions (both free and paid-for) of the MaxMind GeoIP databases/ APIs, do indeed supply timezone information (it returns "Europe/London" for my timezone.) I can't remember whether the old version of their GeoIP system did the same, but it works very well now! The MaxMind fields are named "time_zone", "time_zone_name".

2018年07月19日39分31秒

Link only answers are discouraged, because if the link disappears, the answer ceases to be useful; and because without following the link, readers don't know whether it gives a good answer. In this case, you could clarify that this is a 3rd-party library which takes a database-based approach to identification, and maybe explain some of the principles of its operation.

2018年07月19日39分31秒

This! This is the way to go. Simple library, handles DST properly. Other answers are full of WTF and many don't do DST.

2018年07月19日39分31秒

This library is very clever. It works by querying current offset to UTC, then adjusting JavaScript Date object time by adding or substracting seconds until offset to UTC changes. Using this method this library figures out many enough DST changes to uniquely identify the timezone. I think the library could have even better performance if it did binary search instead of linear search. The return value is an IANA zone info key (aka the Olson time zone database).

2018年07月19日39分31秒

This worked for me! Read the comments under the blog post for a couple updates to the code.

2018年07月19日39分31秒

This will still only return the standard offset for the time zone, such as +02:00. It will not give you enough information to determine the time zone of the user, such as Africa/Johannesburg or Europe/Istanbul. See the timezone tag wiki.

2018年07月19日39分31秒

i do like this, but i might have something that checks the current $_SESSION['time'] and only get the javascript to reload if its different

2018年07月19日39分31秒

It's probably easier to use a Cookie than a Session to transport this, since locking and unserializing the PHP session may cause slowdowns in your app. For maximum efficiency, you could copy the value into the session and delete the cookie so that it's not sent in subsequent requests.

2018年07月19日39分31秒

This only returns the current time zone offset - not the time zone. See the timezone tag wiki.

2018年07月19日39分31秒

Edited to include info about doing the same for the time zone name.

2018年07月19日39分31秒

I just went to that website and it was totally wrong :-/

2018年07月19日39分31秒

AdamLassek: possibly interesting information, but can you explain why?

2018年07月19日39分31秒

AndréCaron It says I'm in Irvine, CA when in fact I am actually in Omaha, NE.

2018年07月19日39分31秒

AdamLassek OK, so it works for you, but you have nothing to support it being totally wrong, then.

2018年07月19日39分31秒

AndréCaron It's totally wrong for me, so I am advising skepticism of that site's accuracy.

2018年07月19日39分31秒

This is a Javascript function, not a PHP function.

2018年07月19日39分31秒

Also, it only returns the current time zone offset - not the time zone. See the timezone tag wiki.

2018年07月19日39分31秒

$unix_timestamp_ofshiz ? Something is missing here and doesn't quite work ,even though this seems like it could be a good answer.

2018年07月19日39分31秒

Why did you repost an identical answer (by John Isaacks) from 2 years ago: stackoverflow.com/a/1809974/836407 ?

2018年07月19日39分31秒

Also, it only returns the current time zone offset - not the time zone. See the timezone tag wiki.

2018年07月19日39分31秒

The link is dead. I think this is the alternative link: devproconnections.com/article/aspnet2/it-s-about-time-122778

2018年07月19日39分31秒

The article is available as PDF form here too: app.box.com/shared/bfvvmidtyg

2018年07月19日39分31秒

The method of converting UTC server time to local client time described in this article is wrong. Using the current client offset to adjust UTC times on the server will result in incorrect "local" times for half the year for client locales that observe daylight savings time. Consider this scenario: a client in the UK on 14 Jan 2013 (GMT+0000 Standard Time) sets a date and time of 21 Aug 2015 14:00 (GMT+0100 Daylight Time). This gets normalised on the server to 21 Aug 2015 13:00 UTC. On the day this occurs the client offset is 0 so the time sent back to the client will be 21 Aug 2015 13:00.

2018年07月19日39分31秒

Valid point, but I didn't claim this to be a bullet-proof solution. If you need to implement a really time-sensitive solution, say a train ticket booking application, then you need to find a more comprehensive (and complex solution). However, for many apps this would not be an issue. Because in many cases we want to localize GMT values for current session. Now, if you have an application that needs to save a time stamp for some even in the future and it cannot tolerate DTS, then a proper way would be to present an option to save time directly in GMT. If you know a better option, please share.

2018年07月19日39分31秒

Looks like api.easyjquery.com is no longer available

2018年07月19日39分31秒

This doesn't account for "daylight saving" adjustments - a user in Dublin would match your 'Europe/Dublin' in winter, but 'Europe/Belgrade' in summer. If you're going to use the current offset, all you can reasonably assume is that offset, not a geographical identifier.

2018年07月19日39分31秒

Unfortunately, that header seems to be mainly designed for responses, not requests: "A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server." I just checked, and Firefox does not send it.

2018年07月19日39分31秒

The function name tells everything about its accuracy ;-)

2018年07月19日39分31秒