Note: The timezone fixer in the initial release of The Bug Genie 3.2 may not work if you have a huge number of issues and comments, as the process is very intensive. We will be performing further changes in the future, and a CLI task to perform this operation will be in a subsequent release of The Bug Genie 3.2. We therefore do not recommend using this tool if you have over 500 issues.
It’s a well known fact that The Bug Genie’s timezone support doesn’t work right in 3.0 and 3.1. One of the more serious bugs was with how timestamps were stored: they were stored in the timezone of the user who caused the action (i.e. opened the issue), and then adjusted to the timezone of the user viewing the thing which involved at time. Therefore, if you both created and viewed an issue which was opened at 03:00UTC, and your timezone is +3, it would be stored as 06:00, and you would see it opened as 09:00.
The cause of this is fixed in The Bug Genie 3.2, and new timestamps will be stored as UTC, so only your timezone offset is applied. This will fix your timezone problems for new issues, comments and so on, but not for previous ones. This is why the upgrade script gives you the option of fixing your timezones.
How does it work?
The script, if you ask it to, will go through every item in the database which involves a timestamp and will remove the offset coded into the database.
We look at the timezone of the user who caused the action (if he has one set, and it isn’t ‘sys’), and if one can’t be found we use the system timezone instead. Also note, if the guest user made a change, then the system timezone will also be used. If the outcome of this is UTC, then nothing needs to be done as there will be no error.
If, on the other hand, it is not UTC, then some work needs to be done. We can then perform the offset change on that timestamp, and this should in the majority of cases lead to the correct result. The advantage of this way is we catch cases where the user timezone is different to the system timezone.
There may still be some times which are incorrect, for example if either the user or system timezone had ever been something different prior to what it is during the upgrade, or if the user who caused the change cannot be identified (this is the case in the builds and milestones table). There is nothing that can be done in these cases to improve the accuracy, as we are suffering from either a lack of history of timestamp settings or users who performed actions, and so we give the option of disabling this conversion. You can also turn it off if you just want your timestamps left alone.
What will it convert?
Times will be corrected in the following tables:
- builds (will be corrected based on system timezone only)
- editions (will be corrected based on the system timezone only)
- issues (posted, updated and being worked on since times)
- milestones (will be corrected based on system timezone only)
- projects (will be corrected based on the system timezone only)