We’ve rolled out some changes in Project Online recently to help our customers answer questions like the one in the title with confidence – by respecting the time zone settings of user and tenant – and hopefully displaying the time you would expect to see if you just saved a project, rather than PST or UTC which we were showing you in some pages. We have a couple of documents published on this and I hope to give you a few examples of which setting drives which timestamps. One first piece of advice – have the same settings in all places (where practical). More on this later.
We have a new section in the Getting Started content in Step 3: Set up shop in Project Online:
And I’ll repeat the links here so you can click them:
My example will start with no specific configuration of the user’s Office 365 account – and also a miss-match to the PC time zone – and show how to correct things for a consistent time.
The time zone for your site is generally set to be the time zone where most of your regular users will be located. Unless your users change their own time zone they will also default to this for their Office 365 time zone – which drives some of the dates in Project Online (mostly the grid contents). In my examples for this blog I have my site configured for UTC+8:00 Kuala Lumpur, Singapore.
And for reference I am writing this blog on Wednesday afternoon March 16th 2016, around 3pm – in Seattle – so Pacific Daylight Time (UTC-7:00 – we changed our clocks last weekend). My pretend user is based in Copenhagen (UTC+1:00), but is remoting onto a machine in New York EDT (UTC-4:00) which has its clock set on New York Time.
My user also has not set their Office 365 Regional Settings (yet). By default these will follow whatever is set for the site. To get to these settings go to the menu under your Office 365 picture – and select About me, then on the next page Edit profile – finally click the ellipses next to Details and click Language and Region. This is our starting point – note the highlighted option.
If I edit and save a project (3:19pm PDT) I see the following time and date:
These dates are coming from the time zone of the PC (in this case set for EDT which is 3h ahead of Seattle) – which gets used for the timestamps in status messages such as these.
However, the queue shows this:
These times are shown using the Site Settings – and are Singapore times – already tomorrow. As an aside I also set the English (Singapore) locale – so the date format is dd/mm/yyyy. These are driven by the site settings, as my user has not over-ridden these with their own regional settings. Most grid times use the time zone of the site – or the user if they have configured one.
So let’s put this right (and remember – I am in Copenhagen).
Navigating to my Language and Region page (as mentioned above) I can select Always use my personal settings – then the other configuration options become available and I can select (UTC+1:00) Brussels, Copenhagen, Madrid, Paris – and I’ll also change locale while I’m there to Danish (I’ll leave the language as English…) then Save all and close. I need to open a fresh browser to get the change to take quickly.
My queue now looks like this – and the times are looking good (for Copenhagen – currently 8h ahead of Seattle)
However, my status message on the Project schedule page has a split personality.
The times are still the same as the earlier screenshot – and New York time 6:18pm – but picking up the Danish locale for the format and showing 18:18 on 16/3. This time, as mentioned earlier is being driven by the PC time zone. Correcting this to match my Copenhagen Office 365 time zone in the Windows 10 PC I am remoted to should fix that:
So to recap
- Set the time zone for you PWA site to the one where most of your users are based
- Have any users outside of this time zone set their own local time zone in their Office 365 Profile (this drives grid based dates, as well as other Office 365 dates such as doclib timestamps)
- Make sure the PC time zone also matches the Office 365 time zone of the user (this drives status message times)
Reports from OData will always show data in UTC – so from the same project above I will see in my OData feed – 1h behind the Copenhagen time.
It is also worth pointing out just for completeness that Project itself has no concept of time zones in the plans – dates will not change if you open a plan in Singapore time compared to Seattle for example – they always assume local time – wherever you are. If you want to use different time zones then you could specify different working time calendars – and decide what your reference time zone is.
Also noticed when writing this that my Outlook Web Access has its own time zone driving the ‘current time’ in the Calendar – so one more thing you might need to check – but this does not affect PWA.
I hope you like the new abilities to have a consistent and relevant time showing in the various screens in Project Online – this has certainly reached my test tenant – it should be available on your sites too!