Important note Retirement of icTime and Retirement of biz on December 29th, 2023
Timezone Issues
There is a fundamental difference in how JIRA handles work logs regarding the timezone of a user who logs works and how this is done. In certain scenarios, this will lead to a situation where the same work logs will have a different time/date depending on if you look at them in JIRA or in ictime.
All this is only relevant for you if you have users in different timezones (= having different user timezone settings in JIRA) and/or a server that operates with a different timezone configuration (compared to all your users)
How JIRA Saves Work Logs
JIRA assumes that work is logged on server time and converts it from the "user time" to "server time" before saving. Once JIRA displays the work log, the user timezone setting (= of the user who is "owner" of the work log) will be applied so that the user gets the correct display. However, unfortunately JIRA does not include the timezone information into the work log. As a weird consequence, this means that when a user changes his/her timezone (e.g. because the user works in a global company and moves to an office in a different country), all existing work logs will now show a different time (and maybe even date). This is not correct, as a user would definitely expect his old worklog report not to change just because he/she now works in a different timezone.
How ictime Saves Work Logs
ictime saves all work logs into the same table like JIRA, so in general, ictime can use JIRA data and JIRA can use ictime data (important if you disable or uninstall ictime). For dates/times in work logs, ictime uses the timezone of the user profile in JIRA. That means that the server date is taken and calculated with the timezone of the current user. However, ictime does never convert times into server times when saving. Doing this would only be correct if you add the timezone information, and this is not supported by the existing data structure in JIRA. That means that ictime saves the time and date exactly as it is applicable for the current user logging work. This simply reflects the time & date according to the user timezone setting at the moment of logging work.
Times are usually not taken from the server, but entered by a user - that means that ictime can't control if a time is "true" or "correct" in a strict sense as this decision is a user decision. If you use the clock icons as helpers to insert the current time from-to for a work log (see e.g. Log Work), the system uses your individual client machine time. If your system clock is not correct, "incorrect" times will be inserted. However, the date "timestamp" is retrieved from the server (and corrected to the current user timezone) and might be slightly different as either the server or your client time might not be absolutely correct.
Possible Conflicts - Date & Time Difference in JIRA and ictime
At the moment where a user timezone is not the same like the server timezone, the timestamp saved into the JIRA database will not have the same date/time for JIRA and for ictime. This leads to problems when
- you use JIRA and ictime at the same time to log work,
- you work with historic JIRA work logs in ictime
- you work with ictime work logs in JIRA.
No Solution for this Issue
It is not possible to solve this problem, as JIRA does not provide the data that would be required to solve the problem and as in general the way JIRA handles this use case does not seem to be correct so that is does not make sense that ictime does it the same way JIRA does (other plugin vendors have taken the same decision, see http://www.tempoplugin.com/faq/why-is-there-a-time-difference-between-my-jira-worklog-and-my-tempo-work-log/). This means:
If - and only if - you have the situation that user timezones and server timezone are not the same, be aware that
- ictime and JIRA will save a different date/time (so you should never use JIRA and ictime at a time to log work - usually ictime will do everything that is technically possible to prevent that, see General Configuration)
- Using historic JIRA work logs created before ictime was installed means that dates/times will be displayed "wrong" (for those cases affected by a timezone difference) because ictime will not apply any timezone of the user who is owner of the work log, i.e. everything is displayed as it was saved in server time and not as it was entered in user timezone time. When editing such data, "wrong" data will be saved.
- Using work logs created with ictime in JIRA means that dates/times will be displayed "wrong" (for those cases affected by a timezone difference) because ictime will not apply any timezone settings of the user who is owner of the work log because ictime can't know that this ia a "JIRA work log" as both rely on the same data structure. So the "server time" timestamp is taken without any correction. When editing such data, "wrong" data will be saved.
As there is no solution for this, either don't do one of the above, or only do it being sure that possible time/date differences do not affect you for your purposes (like reports or accounting).