Why isn't convertToTimeZone working as expected?

[Bentley_ Andrea]

I'm using Jira Software Cloud, and I've got an automation to set the Due Dates of each issue relative to the Sprint's End Date. For example, Dev tasks need to be completed 5 business days before the end of the sprint. Because the Sprint's End Date is stored in UTC, I keep getting a date that is one day ahead. I have tried to convert to my time zone (US/Eastern), but it doesn't seem to be working? Just to test it, I set up an automation that only writes to the Audit Log.

Here is my Sprint information: 

The end date is actually 3/25, but I assumed once I converted "3/26/2025 12:00 AM" from UTC to US/Eastern, it would be 3/25.

This is what I'm logging in the automation: 

And these are the results in the Audit Log:

Why are the converted dates still 3/26 and not 3/25? What am I missing?

[Bentley_ Andrea · Accepted solution]

As a workaround, I'm now using: 

{{issue.sprint.endDate.convertToTimeZone("UTC-06:00").jqlDate}}

And to get the Developer Due Date:

{{issue.sprint.endDate.convertToTimeZone("UTC-06:00").minusBusinessDays(5).jqlDate}}

But I'd still like to understand why converting to my time zone didn't work?

Is the Sprint's End Date of 03/26/2025 12:00 AM already the Eastern time zone? And I just needed to subtract a minute?

[Bentley_ Andrea]

Okay, so after WAY too much time and frustration, I answered my own question. I'll share here so maybe I can help someone else.

When I viewed the sprint information: 

The "End date" of 3/26/2025 12:00 AM is already converted to US/Eastern because that is the time zone I have set in my profile. But the date that is actually stored as: "Wed Mar 26 05:00:00 GMT 2025", which is what I saw when I logged sprint.endDate. 

IMNSHO, Jira should not have made "3/26/2025 12:00 AM" the End date when we selected a 4 week sprint - it should have been "3/25/2025 11:59 PM", which would have solved some of my problems.

There are several ways to work around both the time zone conversion and the end date being at midnight. What I ended up choosing is:

{{triggerIssue.sprint.endDate.minusHours(6).jqlDate}}

By subtracting 6 hours, I compensate for the 5 time zone difference AND the midnight setting. And if someone changes the sprint end date to something more logical, like "3/25/20256 11:30 PM", it will not negatively impact that calculation. And using jqlDate strips off the time part, which I don't need anyway.

[Vishal Biyani]

@Bentley_ Andrea 

As per the documentation only time part is converted not the date.

[Bentley_ Andrea]

That's not how date/time conversion works. If you convert the "time" of March 26 12:00 AM UTC to US/Eastern, it's March 25 7:00 PM - changing the time affects the date when it crosses the midnight line.

[Trudy Claspill]

Hello @Bentley_ Andrea 

You are not specifying valid timezones for the conversion function.

As per the documentation for the function:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/#Convert-timezone-date---

Valid timezone codes can be found here:

https://joda-time.sourceforge.net/timezones.html

That list does not include codes such as "UTC-06:00".

For the U.S.A. east coast timezone the valid codes are:

• America/New_York
• US/Eastern

[Bentley_ Andrea]

I AM using "US/Eastern" in the second example. I also tried "UTC-5" which I saw as another way to do it. 

[Trudy Claspill]

My apologies. I overlooked that among the examples.

[Bentley_ Andrea]

My apologies for my tone - tired, cranky, and frustrated with the issue!