TimeZone and timezone offset not being set correctly from Automation Rule

[Julian Governale]

I have an automation rule that will add the planned start date of the change request from a custom field into the description field so that we can include this information in approval emails.

What we have noticed lately is some users' timezones are being incorrectly set in the description field. 

Here is the automation smart value we are using to set the planned start date based on the reporter's timezone into the description field

*Planned Start*: {{issue.customfield_10922.convertToTimeZone(issue.reporter.timeZone).format("MMM dd, yyyy h:mm a (O, z)")}} 

At the end of the format, we are setting "0" for the localized time-zone offset and "z" for the time zone name i.e. EDT, CST etc

Lately, this rule is no longer working as expected as the timezone and time zone offset that is being formatted in the description field is not reflecting the reporter's profile settings all the time, i.e. the reporter of the issue is located in China (+8, CST), but the timezone in the description field is showing -4, EDT.

We checked the user's profile and validated their profile time zone is Asia/Hong Kong and their profile visibility is set to our organization.  Our system's default timezone is America/New York which i would think is the defaulted value if the Associates profile timezone is not public.

What other aspects might cause a reporter's timezone to reflect something other than what is set up in their profile?  Any other area's i can look at?  Our accounts are managed if that does make a difference.

Here is an example of me changing my TimeZone and it not being reflected in the description correctly.  I am the reporter of this issue

CURRENT PROFILE TIMEZONE

DESCRIPTION AFTER UPDATE OF START DATE - ACCURATE

UPDATED TIMEZONE TO ASIA/HONG KONG

DESCRIPTION AFTER UPDATE OF START DATE - INACCURATE EXPECTED  GMT+8, CST

[Miqueas Milanesio _Appricity_ · Accepted solution]

@Julian Governale  Did you manage to solve this? It would be really helpful as I'm dealing with a similar issue.

[Julian Governale]

Hi @Miqueas Milanesio _Appricity_ , the issue at the time of building this rule actually was not smart value related, but its due to the user's profile visibility for the local time. 

If the visibility isn't set to "Anyone" the system can't retrieve their local time.  I believe this is due to security reasons on the Atlassian side to have this visibility setting not be "Anyone" by default. 

We instructed our users to access their profile and make it visible to anyone if they would like but not required. For the ones that did this update, it is working.

Atlassian account