Knowledge Base Articles
Knowledge Base Articles
Breadcrumbs

How Tempo Timesheets Handles Timezone and Daylight Saving Time (DST)

Problem

When a region permanently abolishes Daylight Saving Time (DST) or changes its UTC offset, Jira Data Center administrators often need to change the system default timezone or remap user profiles to an equivalent permanent timezone (e.g., reassigning users to non-DST regions like America/Phoenix or America/Whitehorse).

Administrators commonly need to confirm:

  • Does Tempo Timesheets for Jira Data Center maintain its own independent timezone or DST calculation logic?

  • Will changing system, JVM, or user profile timezones corrupt historical worklogs or shift logged dates?

  • Are there technical ramifications across the cluster or database when updating timezones?

Solution

1. Single Source of Truth: Jira Core and the JVM

  • No Independent DST Engine: Tempo Timesheets does not maintain custom timezone tables or independent DST calculation logic. It relies completely on the underlying Jira Data Center platform, which in turn queries the Java Virtual Machine's (JVM) Time Zone Database (tzdata).

  • Cluster Uniformity: In Jira Data Center, all cluster nodes run the same Java runtime environment. Any timezone definition recognized by the host node's JVM and Jira configuration applies immediately to Tempo.

2. Historical Data Integrity in the Database

  • UTC Storage: Worklog timestamps in the Jira database (worklog table and Tempo tables) are stored normalized to UTC or as absolute calendar dates (startdate).

  • No Data Corruption: Changing a user's configured profile timezone or the default system timezone does not alter historical database rows or recalculate past approved timesheets.

3. Impact of Changing User Profile Timezones

  • Safe Transition: Remapping users to another timezone with the same UTC offset (such as switching from a region dropping DST to an equivalent constant UTC-07:00 zone) is safe.

  • Worklog Display: Timesheet grids and daily totals display according to the user's active Jira session timezone. Because the UTC offset remains identical, worklogs do not jump between calendar days.

Administrator Best Practices for Jira Data Center

  1. Update the JVM Timezone Database (tzdata):

    • Ensure all Data Center nodes are running an updated Java runtime (JRE/JDK) or use the Oracle/Temurin Java Time Zone Updater Tool (TZUpdater). If Java's bundled tzdata is outdated, Jira may continue applying old DST transition rules automatically.

  2. Align Node JVM Arguments:

    • Keep the -Duser.timezone=UTC setting uniform across all cluster nodes in setenv.sh / setenv.bat. Keeping the underlying JVM clock on UTC prevents cluster-node timestamp drift.

  3. Bulk Update User Profiles (if needed):

    • When updating user timezones across an organization, update the default timezone in Jira Administration > System > General Configuration.

    • Note that users who have previously customized their personal profile (Profile > Preferences > Time Zone) will keep their explicit setting unless updated directly or updated in bulk via Jira administrative scripts/REST API.