Hi Mark and thanks for the time to give your feedback on this problem,

we also believe that there are important use cases where knowing the historically accurate date/time of execution is desirable.

We agree. That is why I would consider it a bug that by changing the server timezone, you loose that accuracy.

If Tempo as a JIRA plugin have decided to use worklogs in a manner that is incompatible with the way JIRA has defined them, then this is rather unfortunate, but cannot be considered as a bug in JIRA.

While unfortunate, this is not quite correct. Tempo decided to use the worklogs as they were defined in JIRA back in 2007 when Tempo was developed. In 2011, JIRA changed that definition with JRA-9. We were not able to incorporate those changes without loosing crucial functionality of our product.

On the other hand, I can see why Tempo would want to get different kinds of information out of the worklogs - if they wanted to raise an Improvement request with a concrete plan for extending the current Log Work functionality in such a way that is is backward compatible but gives them enough information for there own purposes, then we might consider this.

I think that it goes hand in hand our needs if you want to eliminate the problem with changing server timezones. If you include the user timezone with the worklog so that it is easy to translate both to the server time and the actual time, then we could use that information to support both use cases. However it might not be as simple as that because there is no easy way to query for worklogs in JIRA API. But I am sure we could find a solution if the timezone information is included in the worklog metadata.

We can collaborate on a concrete plan with you but it would be good if you could assess the bug I described with the server timezone and if that is something you consider fixing.

Many thanks,
Viðar

Thanks for the thorough explanation mlassau.

lreilly Given Mark's explanation I am resolving this issue as not a bug.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

JIRA treats all date/time fields as absolute points in time stored as UTC and converted to and from the user's timezone during input or output.
(On the other hand we treat all date fields as relative dates, because a date is a 24 hour period in time not a point in time and this makes it significantly different).

A Work Log in JIRA is a combination of a date/time that the work started and the period of time that was spent.
The date/time that the work started is stored as an absolute value in UTC.
Not only does this make it consistent with all the other date/times in the system, we also believe that there are important use cases where knowing the historically accurate date/time of execution is desirable.

If Tempo as a JIRA plugin have decided to use worklogs in a manner that is incompatible with the way JIRA has defined them, then this is rather unfortunate, but cannot be considered as a bug in JIRA.
On the other hand, I can see why Tempo would want to get different kinds of information out of the worklogs - if they wanted to raise an Improvement request with a concrete plan for extending the current Log Work functionality in such a way that is is backward compatible but gives them enough information for there own purposes, then we might consider this.
Of the top of my I would guess we could add an extra field to the worklog storing the user's timezone at the time of writing. Whether that would be sufficient, or if Tempo would also require new JQL fields or something, I am not sure.

1) I am in Sydney and I am reviewing a timesheet of a user in London. When in JIRA, the London user will appear to have been working during the night. Technically it was night in Sydney but that is irrelevant as the user in london did work during his regular day hours.

Whether you think this is relevant or not really depends on the use case for which you are using work logs.
If you are using worklogs as a way of billing customers (which is not what it was designed for) then you may think it is irrelevant.
If you are using JIRA eg as a 24-hour support system, or for IT tracking change management on global infrastructure, then knowing when the work was actually done can be very important.

That would only happen if he used the built in Log Work functionality of JIRA because JIRA will convert his input into the server time (4pm the previous day) and store it that way. Tempo will display what was stored on the server so it will appear on the previous day as you said.

To combat this, most companies disable the JIRA Log Work and Worklogs modules in the UPM and just use Tempo for worklog purposes. This will remove all surprises with particular users and for accounting but you will still have some issues with burndowns and other JIRA reports.

"But if you view the worklog in Tempo, then it will appear just as the user entered it." - it doesn't, it logs the time at 4pm the previous day?

Lisa, it depends on where you view the work. If you look at the worklog in the JIRA UI (e.g., the Worklogs tab at the bottom of the issue view), then it will appear to be the wrong date and time. But if you view the worklog in Tempo, then it will appear just as the user entered it. We can't take care of the timezone with the current implementation because like you noted, users change timezones and even worse, servers change timezone as well. NB that the timezone information is not stored with the worklog so if you make any changes to either the user or server timezone, then you corrupt all existing worklogs that were stored using a timezone conversion.

From a colleague in Vancouver, when our JIRA instance was hosted in Dublin: "Logging work "with Tempo" seems to log work at 4pm on the previous day (perhaps it logs our work at midnight UTC Dublin time, and then converts it to PDT Vancouver time). The other option just to log your work in JIRA seems to log work correctly - at the exact minute that you logged your work."

It seems to me that the issue is that Tempo needs to be aware of what timezone you are in if you move from London to Sydney or Dublin to Vancouver. That JIRA needs to stop treating the entries as system timestamps.

"It is fine to have timezone specific timestamp to system events such as when a comment was made or issue was created. If you don't, then burndowns, reports, and other UIs that use user input will never make a complete sense." — system timestamps mean burndown and any other Agile reports do not make complete sense.

The core problem is that the date field of the worklog is a user input but JIRA now treats it as a system timestamp. In Tempo, we want to preserve the user input at all cost. This means that we do not convert the user input to server time (timestamp) because that is a one-way conversion. If the user changes his timezone, then the historical data becomes incorrect. Here are two use cases that Tempo handles but are not possible with JIRA's approach:

1) I am in Sydney and I am reviewing a timesheet of a user in London. When in JIRA, the London user will appear to have been working during the night. Technically it was night in Sydney but that is irrelevant as the user in london did work during his regular day hours.

2) I am working in London and log my work, then I relocate to Sydney and continue to log more work. Now it will appear that I used to work during the night but recent worklogs appear to be worked on regular hours.

These are trivial examples. Now imagine that I need to prepare an invoice for September or I need to report a financial quarter to accounting. What happens to worklogs that user specified to be carried out on 30th but due to timezone differences, JIRA will tell you that it was actually October 1st?

We believe that the worklog date should be treated the same way as other user entered dates like version start/release date, sprint start/end, and due dates. Those dates are timezone agnostic. It is fine to have timezone specific timestamp to system events such as when a comment was made or issue was created. If you don't, then burndowns, reports, and other UIs that use user input will never make a complete sense.

Viðar Svansson
TEMPO Product Manager