One of our Clients brought our attention to one of the problems with time zones. You may not have noticed that in you tinyPM instance especially if you host tinyPM on your own. But they were using our hosted version where this problem turned out to be easier to spot.
So think for a second what does it mean when you say that your iteration start on Monday, July 4th?
Well at the first sight it may appear to be a strange question… at least if your whole team is co-located. But what if part of your team sits in London, part in New York and the rest in Sydney? What does the 4th of July means to you then?
Let’s assume we’re in London. In a face to face conversation you would probably mean July 4th around 8 am (which, in other words, means the start of your working day). Ok this will remain the 4th of July for New York (but around 3 am) and also 4th of July in Sydney (3 pm).
However when you use electronic tools and you enter dates without specifying time, this usually means 4th of July at midnight. Instantly your team members from New York will see it as 3rd of July (7 pm).
Of course handling different time zones is not a problem for the tool itself. The question is more general. How do you define your project dates in highly distributed environment? We would choose a single time zone for the project to be used for raw dates so that everybody knows that what we mean when we say July 4th, 2011.
This is also what we’re introducing in tinyPM 2.5.6. You may now define a project time zone. It will be presented next to all date fields which do not require time (like iteration start dates and release dates).
As usually you may find the list of all changes in tinyPM 2.5.6 at: