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 datesThe 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. |