Not respecting timezones

• Automation rule not respecting the custom field date/ time value although converts the time to UTC which is the JIRA default time when a smart value is included. The Summary should be updated with the same time in the 'mediumDateTime' format, but Jira converts the time in the custom field to its default time which is UTC and updates the Summary section. Found this link and it looks like for all smart values the time is being converted into Jira's default timezone. Steps to Reproduce
  • Create a custom field with date/time picker and add this field to a 'Create Issue' screen on a service project.
  • Create an automation: When an issue is created with a particular verbiage in Summary section, trigger the automation to update the 'Summary' section as following: "issue.ExactDateTime.mediumDateTime". --/ ExactDateTime is the DateTime custom field
• The smart value Now returns the current date and time in UTC+00:00, as documented here: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/#Current-date-and-time---now--  This is not, however, clearly flagged in the automation rule UI, which leads users to assume that the value will match their own timezone. Given the way this value functions, it would be best not to refer to it in the UI without further info. Workaround: You can set your timezone of choice https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/#Convert-timezone-date---
• Once automation is triggered and the audit log records this run, timestamps are saved according to the browser timezone and ignore any configuration made in the instance default timezone or user AA account timezone preferences.  Expected result is that Timestamps being updated according to the AA preferences and match the timestamp in the issue history, but actual result is that Automation rule audit log timestamps stay the same no matter the configuration change regarding the timezone preferences. Changing the Instance timezone from jira/settings/system/general-configuration also results in the same behavior
• If a user sets any timezone in personal settings, it is not reflected when using the smart values: reporter.timezone or assignee.timezone And instead the system default is used. This occurs even when using the correct cannonical ID found on this page. 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).