Eliminate Confusion with Time Zones in SharePoint Online and SharePoint 2013 On-Premises

Many companies with users spread across multiple time zones experience issues with the dates when using SharePoint on-premises and SharePoint Online. By default SharePoint users see all dates and times in the time zone of the site, so all the visitors has to guess what is the actual time of all those modify dates and event start times. There are multiple ways to eliminate this confusion:

• Out of the box - Update your user profile to always show SharePoint dates in your current time zone. While being a great feature, it is somewhat hidden from the user and relies on self service (user has to do that by himself)
• SharePoint Time Zone App - my company (Sharepointalist) recently published new free SharePoint App (works both on-premises and SharePoint online), which allows you to place small widget (app part) on any SharePoint page, and it will show user time zone of that page. It means that when you create a calendar and share the link with all users, they will immediately see what time zone is that in. This app also provides a quick link to configure user profile to see all dates in the right time zone, which is very convenient to the user. Please try this app, it is totally free and very easy to install and use.

Attaching couple screen shots of the app

Additional SharePoint 2013 App Part Tokens

There have been a very interesting article at SharePoint Developer Support Team Blog. It discusses editMode parameter, and also mentions WPID parameter in the code sample. This got me into researching this matter.

So far we had two MSDN articles, discussing tokens: URL strings and tokens in apps for SharePoint and URLs and tokens in SharePoint 2013.

They both lack a few important App Part tokens (parameters). Here they are:

• editMode - has two possible values: 1 or 0. 1 means the web part (not Page) is currently in Edit Mode.
• WPID - represents a WebPart.ID (sample value is "g_f5ac6d08_5b6f_41ea_90d1_0cc8a030061c").
• WPQ - represents a WebPart.ClientID (sample value is "ctl00_ctl33_g_f4a94a49_ce63_4c7f_ba05_884b17132672").
• WebLocaleId - represents a web.Language.ToString(CultureInfo.InvariantCulture) (sample value is "1033"), which is a Language Id.

You can use all those tokens in the URL, the same way as you use custom properties, without the need of adding actual properties. All tokens are case sensitive.

<ClientWebPart Name="ClientWebPart" Title="TestAppPart" Description="TestAppPart" DefaultWidth="600" DefaultHeight="300">
  
  <Content Type="html" Src="~appWebUrl/Pages/DemoPage.aspx?{StandardTokens}&amp;wpId=_WPID_&amp;editmode=_editMode_&amp;wpq=_WPQ_&amp;weblocaleId=_WebLocaleId_" />

  <Properties>
  </Properties>

</ClientWebPart>

There are a few additional tokens (parameters) not allowed for the app parts, but allowed when rendering XmlWebPart, PageViewerWebPart, ImageWebPart, DataViewWebPart and DataFormWebPart. I did not try them out though, so your feedback on their usage is welcome. Here they are:

• LogonUser - represents a context.Request.ServerVariables["LOGON_USER"].
• WPR - represents a Web Part Resource Path : (web.Url + "/" + web.TypeCache[type, web.IsAppWeb, false].WebRelativeClassResourcePath).
• WPSRR - represents a Web Part Server Relative Resource Path : web.GetServerRelativeUrlFromUrl(web.TypeCache[type, web.IsAppWeb, false].WebRelativeClassResourcePath).