Detecting the Current User’s Regional Settings with jQuery
I noticed a nice little trick going by in my Twitter feeds today.
I’ve always wanted to know how to do this. Displaying the right formats for dates and times as well as the right offset from UTC is a real challenge from the client side. There’s a fantastic library called Moment.js that I use on just about every project these days, but it only does the full job if you know the user’s locale and timezone.
The post on StackExchange gave a little snippet of script which came from an old MSDN Forums post from 2009. Kudos to Peter Holpar for the original idea.
The script basically screen-scrapes the values from the Language and Region settings page. I don’t mean that disparagingly at all; screen-scraping is how the SPGetCurrentUser function in my SPServices works. If it gets the job done and is reliable, the old art of screen-scraping – or should we call it plumbing the DOM with AJAX? – is just great.
Note that you’ll need to have jQuery loaded to use its AJAX function.
Here’s the script as-is from the StackExchange post. It was originally intended for SharePoint 2010.
var url = ctx.HttpRoot+"/_layouts/regionalsetng.aspx?Type=User"; $.get(url,function(data){ $(data).find("select[name='ctl00$PlaceHolderMain$ctl00$ctl00$DdlwebLCID']").find(":selected").each(function(){ var lcid = $(this).attr("value"); var cultureInfo = $(this).text(); }); });
I just tested it out in SharePoint Online on Office365 and this is the version that works for me. Note that I simplified the jQuery selectors to look just for the important ending text in the name attribute. I’ve also re-scoped the variables so that they are available outside the $.get call. If you want to use this snippet, you’ll probably need to adapt it for your environment. The alert at the end is jut there to show you that it works.
var url = _spPageContextInfo.webAbsoluteUrl+"/_layouts/regionalsetng.aspx?Type=User"; var lcid, cultureInfo, timeZone; $.get(url,function(data){ $(data).find("select[name$='LCID'] option:selected").each(function(){ lcid = $(this).attr("value"); cultureInfo = $(this).text(); }); $(data).find("select[name$='TimeZone'] option:selected").each(function(){ timeZone = $(this).text(); }); alert(lcid + "::" + cultureInfo + "::" + timeZone); });
Hi, Good post. What about the REST API: /_api/SP.UserProfiles.PeopleManager/GetMyProperties ? Are the values different there?
Anatoly:
Actually, it is different. The URL /_layouts/regionalsetng.aspx?Type=User goes to my settings for the current Web (“Site” to users). Whereas the User Profile settings are for me overall: /_layouts/15/EditProfile.aspx?UserSettingsProvider=dfb95e82%2D8132%2D404b%2Db693%2D25418fdac9b6. These settings don’t always match.
In theory, the settings for the current Web are better to use because those are the settings people get to from the Suite Bar when they go to My Settings. Frankly, I’m not sure how the two interact. One would hope that the User Profile settings would apply first (HR ought to know where I am, thus AD should reflect it) and then My Settings in the local Web would override the User Profile settings if I’ve chosen to set them.
M.
Thank you Marc for your answer. I am very skeptical to this kind of solutions that download a whole page behind the scenes and parses the result. It has an impact on performance. On the other hand if this is the only way to get the desired information, then why not…
Performance isn’t always a problem, but I agree. If there isn’t a useful API, though, we have to create one, in essence. Sometimes screen-scraping can be used as an API of sorts.
M.