Guess current timezone #220
Conversation
|
For the api names, I'm leaning towards this. moment.tz.detect(); // get the users timezone
moment.tz.detect('US/Pacific'); // prefer US/Pacific over America/Los_Angeles
moment.tz.detect(['US/Central', 'US/Eastern']); // add multiple preferred zones
moment.tz.ignore('US/Central'); // remove US/Central from the preferred list |
|
Still looking over the implementation, but I like the direction this is heading. Thoughts:
|
Looks like it is pretty well supported across all but safari, mobile, and ie10 and lower. http://caniuse.com/#search=intl I'll add a try/catch somewhere that checks if
Yeah, I think this is a pretty slippery slope. I think between framing it as a guess in the documentation and adding the more accurate If we did want to try to disambiguate cases like |
timrwood
force-pushed
the
current-timezone
branch
from
b93fe03
to
47ab828
Compare
|
Is this functionality built into the current moment timezone (0.4.0-2015d) yet? |
|
|
| done(); | ||
| }, | ||
|
|
||
| // These tests were built with 2015b data. |
There was a problem hiding this comment.
Were they built manually or with a script? If a script was written, could you also share it to have the ability to rebuild when moment updates with the new data?
|
@timrwood Thanks for the great work! Looking forward for this to be merged! As for the APIs, |
|
Really looking forward to this getting merged! @blake-nouribekian: No, it's not in yet, I wish it was :) I could really use it right about now. |
|
I haven't got this confirmed for sure yet as it comes in auto-reports from several users of a large online service, and I'm not yet sure if the timezones recorded are set by the web app, but if it is so, then the We use jsTimezoneDetect as a fallback if the Intl API is missing, and for now we are going to introduce a simple validation around the Intl API to throw away non-existent timezones and fall back to jsTimezoneDetect in these cases, too. |
|
Is this going to be added to momentjs.com soon? |
|
+1 |
3 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 👍 |
|
+1 Yes please merge this, it would be great to not have to load an additional third party library to detect user's timezone. |
|
For those +1-ing. We all understand that client time zone detection is an important use case, but I'm not 100% convinced that this is ready for merging. There is more analysis to be done. |
|
I've been using this feature. I've had no reports of it reporting an incorrect timezone from various users across the US, UK, Finland, Sweden and Netherlands however that is only a small percentage of all the possible timezones. Just thought I'd say my experience thus far. :) |
|
@JTallis - Thanks, but I wonder...
|
|
No, I only have a small user base and it's not really used in anywhere other than one place, which is fairly noticeable. I do also have three other users from Pakistan, Iran and India. I'll ask users to confirm that the timezone chosen for them is correct and if it's not correct, I can report back. Is there any information you'd need other than the timezone chosen and their actual timezone? |
|
Iran and India are easy to detect due to their fractional offsets. Pakistan could get detected as a handful of other countries, but I'm not sure it would matter since they don't have DST. Thanks, but I think the best thing to do is to run the code through testing on different time zones. We need some grunt scripts that iterate through all time zones, change the system time zone (or env var), run the detection code, and output a list of all matches and mismatches. Probably best to start with a Linux or Mac environment with the same tzdata update as the one being used in moment-timezone. Eventually we'd want to expand it to support Windows zones through CLDR mappings. |
|
Hey, when will be able to use this feature? :) thanks! |
|
can't wait! |
|
+1 For those who can't wait, there's http://pellepim.bitbucket.org/jstz/ |
|
Yes, jstz is good, but since that already exists, we don't want to rush moment's version of this out the door without it being significantly better. We made some progress a few weeks back, but I've been tied up since then (I assume @timrwood has been also). Hopefully I can get some time to focus on this soon and we can get it in the next release. Hang in there! 😄 |
|
Already using |
|
My timezone is America/Sao_Paulo but i see America/Montevideo in the result detected. +1 |
|
+1 I hope |
|
I don't think it's important to correctly detect the region or zone in the world/map. The timezone is important for the TIME setting. If I'm in Madrid but the browser detects "Europe/London" instead of "Europe/Madrid" is ok because it's the same hour right now. |
|
It's the same hour, but there may be cases (I didn't read the whole data set) when it's currently the same time, but the rules did or will change. Imagine for example if it detects "Europe/London" for you, that is saved in settings and then next year the UK shift DST by one week; or worse: decides to go off DST entirely, then half a year you would have the wrong times. It's all theoretical and I can't give an example, but you get the point. |
|
Yes, but it's something you cannot save it. It doesn't make any sense. If you need the timezone of the user, just get it and send it by parameter. Thanks! |
|
What you said makes sense, but it only affects specific cases (user changing the time, or moving to another country) -> it's the user's responsibility and it will probably be less frequent. Plus you can detect time zone changes. That's why they call it "Guess", it's good if it's not really sensitive. And if it is, we just have to ask the users, and make sure they understand that if their situation change they have to update (that's what most websites do) |
|
Since it's something that you configure in your OS (sometimes it's automatic, also on mobile), in my perspective it should be transparent and automatic to users. |
|
You guys know about https://bitbucket.org/pellepim/ right? |
|
@danielgindi That's jstz, it was literally mentioned 3 comments above you... Try |
|
Oh yeah, sorry... I read many comments and then just skipped to the end :) |
|
This has been released in |
|
Congratulations! |
|
Super. Thanks for these functionalities. But can someone suggest what exact i can use to get timezone ? i tried guess and zone but i didnt get any results. actually i am passing a string "Tue, 05 Jan 2016 18:51:18 PST", and trying to get timezone from this to stop converting to any other timezone by checking it. can u pls tell what to use? |
|
@Shobana16 you are using it incorrectly. You should not pass anything - just call it, and get the current timezone string. |
|
I am getting this string as an input from other source. so i am trying to get that timezone. |
|
@Shobana16 You probably want to make a new Moment instance with that string: console.log(moment(new Date("Tue, 05 Jan 2016 18:51:18 PST")).guess());Edit: I was mistaken! See answer by @TWiStErRob below. |
|
ok But i get guess is not a function. :( i have moment version 0.5. do i need any other lib? |
|
You need moment (latest version is 2.11) as well as moment-timezone version 0.5. |
|
yes i have that only. But still i get same error Uncaught TypeError: moment(...).guess is not a function |
|
The last comment from Tim (author) was that it was released in 0.5 and he gave the exact usage: I think what you're looking for is significantly different than the purpose of the feature discussed here, I think you should ask a StackOverflow question to get help to prevent further hijacking this issue. From what I understood you want something ike this: moment(new Date(yourString)).tz("America/Los_Angeles").format("ddd, DD MMM YYYY HH:mm:ss z") == yourString |
|
Thanks @TWiStErRob for clarifying, my moment is a bit rusty! I agree that a SO post would be a better place to seek help with this. |
|
The |
|
|
This adds the ability to guess the browser's timezone. See #138.
Demo
http://jsfiddle.net/bvjxt7jr/11/
Implementation
The implementation is fairly similar to jstimezonedetect. We look through a whitelist of zones and check if the offset matches in both January and June.
There are about 500 different timezone identifiers, and about 60 unique January/June offset pairs in use this year. The limitations of jstimezonedetect also apply here. We don't differentiate between
Europe/BerlinandEurope/Stockholmas they are equivalent in recent years.Whitelisted names
These are the whitelisted timezone names for each January/June offset pair.
Keeping whitelist up to date
It is likely that this list will change based on updates to the tzdb, so we will probably need a way to tie this to data updates.
One problem we will need to solve is how to determine which timezone to use in the whitelist for a given offset pair. For example, there are many timezones that match
-08:00/-07:00this year.America/Dawson,America/Ensenada,America/Los_Angeles,America/Santa_Isabel,America/Tijuana,America/Vancouver,America/Whitehorse,Canada/Pacific,Canada/Yukon,Mexico/BajaNorte,PST8PDT,US/Pacific,US/Pacific-New.The current whitelist is mostly based on the list from jstimezonedetect with a couple additions for new tzdb data. Ideally, we could get data for the population in each timezone and use that to choose the best candidate, but I'm not sure where we could find that data.
User added whitelisting
Because we are just looking through an array of names, we can expose that list to the user to add their own names.
We should probably make a dedicated api for this rather than having to know the internals of whether to push or unshift onto the array.
Bikeshedding
Now the fun part.
There are a few different names we could go with here.
To add user defined whitelisted names, we also have a couple options.