Detecting the Current SharePoint User’s Regional Settings

Brian McCullough (@bpmccullough) pinged me on Twitter today with a question:

Brian was asking about an old blog post of mine where I basically screen scraped the data: Detecting the Current User’s Regional Settings with jQuery. It worked fine in the old days, but I didn’t think it would work anymore on SharePoint Online.

It was bugging me that I couldn’t remember the answer, so I went digging into some SharePoint pages to see what I could see. In two different SharePoint Online tenants, I saw that the _spPageContextInfo object has the following properties:

As I recall, if the userTimeZoneData  is not null, then the user has set their time zone themselves. If it is null, then the user is going along with the webTimeZoneData. I don’t have an example, but I’m pretty sure you can also check preferUserTimeZone  to see if the user wants to have her own time set.

Note that there are lots of other goodies in  _spPageContextInfo as well. The other properties which are pertinent to time zones are:

  • userTime24  – Does the user prefer 24 hour (military ) time?
  • webTime24  – Does the Web display 24 hour (military ) time?

The TimeZoneData  properties are also quite rich, showing the time zone description, the bias from GMT, Daylight Savings Time bias (usually 60 mins, but sometimes 30 mins), when DST starts and ends.

<update date=”2017-10-04″>

Bryan Mathews (@brmathews) reminded me on Twitter that there is a REST endpoint that provides some of this information as well.

If you use the /_api/web/RegionalSettings/TimeZone endpoint, you’ll get back information like this:

This is XML, but the data you’ll get back in JSON is the same. Note that there isn’t as much details here as in the  _spPageContextInfo, but this endpoint is available to you in any page.

</update>

Note that depending on the version of SharePoint you’re running, your mileage may vary.

Does anybody really know what time it is?

 

Advertisements

Beware the Office 365 Group -Based Site Regional Settings!!!

This is a quick post, yet it’s still an important one. We’re using more and more Office 365 Group -based SharePoint sites these days. Even when you know you aren’t going to use some of the goodies you end up with, this type of site is making more and more sense.

<addendum data-datetime=”Sun May 14 2017 10:56:53 GMT-0400 (Eastern Daylight Time)”>
Several people have asked me in other forums the basic question: “So what?” If all dates and times are stored in UTC, does it really matter what the site’s Regional Settings are? Frankly, that’s got me a little bit stumped.

It certainly feels wrong that the site’s settings don’t match its primary locus, but since team members can span the globe, what’s the impact?

I know I struggle as a developer to show everyone things in the right date/time based on their settings, and it feels like the platform doesn’t give us great tools for this. What other issues does it raise? Please add your thoughts and issues in the comments. I’m interested in things other than the usual “The people in Redmond don’t realize that we’re not all in their timezone” stuff – which is basically all I’ve pointed out here.
</addendum>

BUT, there’s a simple problem that can have longer-term ramifications. The default time zone for every new Group-based site we create is PDT, also known as UTC-08:00. You have to go into Site Settings to change it manually for every site you create this way. Since a lot of my clients are in EDT, this is tedious.

I’m guessing no one in Redmond even notices this, because PDT is their time zone. I spot it every time I create a new Group-based site during a migration because Sharegate warns me the time zones of the source and destination sites are different when I start to copy content across. (Yay, Sharegate!)

If you happen to be a non-US person, then ALL of the regional settings are likely to be wrong for you. I’ve checked, and there is no way to change the default here – unless it’s a VERY recent change.

Here are some Office 365 UserVoice suggestions you can run off to vote for:

 

Detecting the Current User’s Regional Settings with jQuery

I noticed a nice little trick going by in my Twitter feeds today.
2014-08-20_19-09-43I’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);
});