Expand my Community achievements bar.

The next phase for Workfront Community ideas is coming soon. Learn all about it in our blog!

Hi all !!! Has anyone got any feedback or experience regarding the use of timezones?

Avatar

Level 2
Hi all !!! Has anyone got any feedback or experience regarding the use of timezones?
14 Replies

Avatar

Level 10
Hi Melanie - I was going to start a thread on this too. I have quite a lot of experience with it (not all good unfortunately!). We have users across multiple timezones in Australia, Asia, Europe, USA and a few other places in between. Non-working days on the Time Off tab can show on the wrong days, depending on whether your PC is set in the same timezone as the person you are looking at (or close to it). This is because Workfront shows you the day (your time) when the person is not working - not the day (their time) that they are not working. This of course means that for anyone managing teams across major timezone differences, it causes problems. The Resource Grid (and Team Builder) shows resource availability and utilisation based on the viewer's PC timezone, rather than the resource you're looking at. This is the same underlying issue/behaviour as above. From a resource Availability point of view, it sort of makes sense mathematically, but not so much practically. e.g. if I am in Australia and looking at a resource in Italy, Workfront shows that they are available to work some hours on Saturday (my time), when in reality they don't work Saturday (their time). Our global scheduling team would like to be able to clearly see which project timezone they are scheduling for and what the availability of the local resources is in that local timezone. From a Utilisation point of view, Workfront also applies the same logic, but this is where it is really impractical. It shows the percentage (or hours) the resource was utilised on each day of the week based on the viewer's timezone on their PC, rather than the resource they're looking at. For us to generate an accurate utilisation report of our Italian or UK teams, we have to change our PC timezone to Italy or UK first, then run the reports and then change them back to eastern Australian time before we can report on Australian users. Creating Utilisation reports for resources across multiple timezones at the same time generates some wierd and inaccurate results. It is fiendishly complicated when you start thinking about how it really should work, however simply from a user's point of view they need to be able to schedule resources in other timezones without having the view distorted by their own timezone.. Project Manager users also get a bit confused by timezones when working with tasks. This is based on the combination of the Project Timezone (from the Project Schedule) and the timezone of the PC. e.g. If a PM based in Australia is looking at a project based in the UK, then a task's 9am (UK time) start time shows as 6pm. If the PM forgets this and starts creating new tasks starting at 9am (Aust time) then when someone from the UK looks at it, their task is scheduled to start at midnight (the morning of the same day). I have suggested that it would be good to have an option in Workfront for the PMs to view and work with times as if they are in the local project timezone. The only current workaround is for the PM to manually calculate all times to the desired time before entering them in Workfront.....or change their PC timezone to the project timezone while editing that project, and then change it back before they work on a local project. Lastly, there is a minor item related to kick-starts - times need to be converted to GMT/UTC before uploading. This is logical but just a gotcha if you aren't aware of it then upload your tasks and wonder why all the times changed. I have submitted support incidents (then feature requests) for all the above items. I have also had a brief conversation with Workfront product management regarding the new Resource Scheduling features and their indication was that they are working on all of this in the new functionality and won't be fixing it in the older parts of the system. If there are any updates on this that anyone is aware of I'm very keen to know as this is one of the biggest areas we want to see improvement. Regards, David.

Avatar

Level 10
<> Great list of problems. Long ago, rather than try to work with those problems, we just agreed to run projects on a specific timezone. “Project Time”. The Military uses Zulu time (which is kind of like GMT). We use the Eastern US timezone. This is not a very considerate method, but it works. Eric ________________________________

Avatar

Level 2
Thanks David - excellent info.... timezones make me a little nervous but we may need to run with them given our use of Jira... I'll keep you posted.

Avatar

Level 2
Hi Lucas, thankyou. I'm starting to build a picture of the issues. cheers

Avatar

Level 10
Hi Eric, Could you elaborate a little on how you standardised to a single timezone? I assume this means that all schedules are configured to use the same timezone, regardless of where the users or projects are located? This would (generally) fix the utilisation/availability reporting issue. Assuming we did use a single timezone for projects and users globally as per the above, how does it address the client PC timezone issue? For us this would mean users in Australia using UK time on their PC (or vice versa), which is not practical for other desktop applications I would expect. Thanks Regards, David.

Avatar

Level 10
<> It was largely an agreement. Then, we had one schedule (Project Schedule) that was Eastern time zone. All projects (for the most part) and all people (for the most part) are on the one schedule. We do have an Alaska schedule, but that is used for projects run exclusively with the team in Alaska. I have not heard of issues translating times on the PC. I know their PCs are on Mountain, Pacific, whatever time zone they live in, but no one has said anything about times being messed up. I’ll have to change the time zone on my PC and see if things still come out - are presented in - Eastern time zone. Look, this is a brute-force way to solve the problem. I’d much rather the server simply translate times into whatever time zone each person is assigned. It does it inconsistently and frustratingly. I haven’t looked at time zones in a while, so maybe I should go back and take another look at it. Inelegant. Eric

Avatar

Level 7
We have noticed that WF display the correct time zone on a document based on your timezone system settings. However, when you download the document, the file properties are tied to mountain time since that's where the WF servers are.

Avatar

Level 5
First off, the option to show timezone on all reports is key. If a user exports a report in Bangalore, its going to look different New York or London. Not sure the best fix but we tend to use the due date for projects and for some reasons the due time standardizes to 5pm pacific standard time, so our european and asian users think the project is due the next day. We are working on teaching everyone to put in times, but not sure why the schedule is going to the system default instead of the user's when they create a project (no schedule is defined on the template)

Avatar

Level 10
Hi Melinda, I guess you know it's possible to show the project's timezone on reports (project or task reports). On project reports, you can directly add it. On task reports, you need to add it via text mode - sample as follows: displayname= linkedname=project namekey=view.relatedcolumn namekeyargkey.0=project namekeyargkey.1=schedule:timeZone querysort=project:schedule:timeZone textmode=true valuefield=project:schedule:timeZone valueformat=HTML If you export a report to PDF, it includes the time the report was run and which timezone it was in. It doesn't do this if exporting to Excel, which may be your point - and this could be a good feature request (e.g. put the run time and timezone on a separate tab of the spreadsheet).

Avatar

Level 5
The challenge is definitely the excel export. If analyst A does a report on all projects closed during May, in Bangalore. The data may be quite a bit different than analyst B in Hawaii reporting on all projects closed during May. And that's one of those really hard to nail down bugs of these 10 projects were closed in June in India vs May in Hawaii. This is especially challenging in follow-the-sun businesses where responsibilities vary by hour of when a project is entered, or you have individuals working in 8+ global timezones. My previous employer had a standard where all reporting in other systems had to be done in Eastern Standard (US) time, and that wasn't something we could push out easily with a system-based timeclock used in Workfront.

Avatar

Level 2
If you are using the API, you also need to take into consideration which server you are hitting to pull the data. If you are encountering a problem with a shift in timezones with multiple data pulls, it's more than likely that you are hitting a different server due to a load balancing issue. We are going through this right now with the API. The solution we are putting in place is to alway call a specific server. We hope that this rectifies the issue. I'll post back if this solves the issue.

Avatar

Level 10
Hi Brady, Could you please elaborate on the API timezone issues? My understanding is that we are hosted on cluster CL01 but when we use the API we connect to our normal instance's URL. Are you saying that you instead need to connect to a specific server? We are starting to build some integration and haven't run into any issues yet so far but this is something we may need to look into. Thanks Regards, David.

Avatar

Level 2
There are a few issues we are encountering. We had the API set to our Site URL. I'm not sure where that instruction came from. We've updated it to CL02 and we are using the StreamClient at the moment.

Avatar

Level 10
Hi all, Today I had the need to change my PC (WIndows 10) timezone to a couple of other timezones and back in order to see time-related data correctly in Workfront, and I thought there must be a faster way to switch. I was able to create a set of simple batch files to run which instantly change the Windows timezone. I have placed the shortcuts on my desktop with some flag icons to make it easy to choose from at a glance. If you would like to use mine, they are attached (no viruses, I promsise....) If you want to create similar batch files for your timezones, just find the name of the timezone in the 'Windows Timezone List' file which is in the 'Batch files' folder. Then copy one of the batch files and edit the corresponding line. Let me know if any queries. Regards, David