Issue Summary

If a user sets any timezone in personal settings, it is not reflected when using the smart values:

{{reporter.timezone}}
{{assignee.timezone}}

And instead the system default is used. This occurs even when using the correct cannonical ID found on this page

Steps to Reproduce

1. Create an issue in Jira with yourself assigned as the reporter and assignee
2. Adjust personal settings so that your timezone is in a different timezone than whatever the current system settings are.
3. Create a manually triggered automation and log two actions (label them to differentiate):

   {{reporter.timezone}}
   {{assignee.timezone}}
   

1. Add another log action for:

   {{initiator.timezone}}
   

1. Run the automation against the issue created earlier.

You will see both assignee and reporter timezones being listed as the system default, while the initiator reflects the timezone you've set in your personal settings. All three should be matching if all three are the same user (which they should be since you are the initiator, assignee, and reporter).

Additionally, some timezones such as "America/Moncton" don't even get recognized despite being a correct timezone ID found in the page linked above (which is referenced in our automation documentation). Jira instead just falls back to the last used timezone instead of the currently set one (you can test this by doing the same above first chaning your timezone to "America/Chicago", waiting a few minutes, then changing it to "America/Moncton". You will see that "America/Chicago" is still being used for initiator.timezone).

Expected Results

Timezone for reporter/assignee should match initiator/reflect the correct personal settings.

Actual Results

Personal settings are ignored and timezone instead uses system default.

Test issue with myself as assignee/reporter:

Personal settings set to "America/Moncton"

My test system default:

Results returning previously set personal timezone of "America/Chicago" and the System default for assignee/initiator of "America/Los_Angeles"

Smart values used:

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available