Why is there a time difference between my Jira worklog and my Tempo worklog?

Answer

This is a known difference between Tempo Timesheets and Jira. The default time stamp for time logged through Tempo is midnight on the date according to the user’s time zone. However, if the user has customized the time stamp and set a specific time then it may result in a miscommunication with Jira's Data Centers. This is because Jira assumes that time is logged on Data Center time and converts it before saving. Jira extends that assumption to its plugins. This means that when Tempo logs time, Jira will “correct” the time to the user’s time zone, even if that was unnecessary. Consequently, you may get a time difference between the Jira and Tempo worklogs. The decision to log time this way was made because it enabled both products, individually, to better serve their users.

Quick solution

Disable the Jira worklog module and use only Tempo to log time. The date entered into Tempo will always be presented as it was entered in all Tempo views and reports.

Examples

There are a number of reasons for why Tempo does not comply with Jira, which relate to data integrity and backwards compatibility. To explain in more detail, let’s look at some examples:

The default configuration in Tempo is that the worklog date is truncated, and therefore, the worklog is saved at 00:00 (12:00 AM).

With a Data Center in Reykjavik, Iceland and a user in Sydney, Australia (+10 hours):

Hours logged on 1/Aug (12:00 AM default) in Tempo would appear
- in Jira's worklog tab as 1/Aug 10:00 AM
- in Tempo (as on a Data Center) as 1/Aug (12:00 AM)
Hours logged on 1/Aug 12:00 AM in Jira would appear
- in Jira's worklog tab as 1/Aug 12:00 AM
- in Tempo (as on a Data Center) 31/Jul 2:00 PM

If logging time with a start time that is enabled in Tempo, things get more complicated. Worklogs added for one day in Tempo can spread over two days in the worklog tab, depending on the start time.

The user logging time is selecting a particular date and time for a reason. It is the day on which the work was completed. If that same user were to go to a country in another Time Zone, he would still expect his old worklog report to be the same as the day before he moved. (i.e., it makes more sense to him that this was logged at 8:00 AM wherever he was at that point in time, rather than having this recalculated to his current Time Zone, which would suggest that this was worked on at 10:00 PM on the prior day.)

A report for the month of July might show different results, depending on whether the report was generated in Reykjavik or in Sydney. Invoices sent out might be missing or adding on a few hours around the start and end of each billing period. This might result in incorrect salary calculations, etc.

In the other word, when you log time in Tempo, it takes user personal time zone setting to set the start date in the database.

Jira versus Tempo work dates

The User Time Zone Feature was released in Jira 4.4. With this feature, a user’s Time Zone can be easily changed. However, the minute you change to a new Time Zone, the dates and times of older worklogs become confusing and even meaningless, as you don’t know the Time Zone in which they were logged.

By not complying with Jira in this matter, we are not in disagreement with how Jira is currently structured. On the one hand, it makes sense to convert time stamps of issue workflow actions to be able to present threads of actions in real time for the user; the life span of such data is short. Tempo, on the other hand, relies on the integrity of its data to create accurate reports over periods of time — reports to calculate salaries and to bill customers. If we were to switch to Jira's model, all of our data would be inaccurate.