How to retrieve version release date to copy to a date custom field?

[Brian Preuss]

I am working on a user request to copy the version release date to a date custom field. I was able to retrieve the date(s) using Jira automation smart value (shown below) and then publish the value(s) as a comment successfully.

{{fixVersions.releaseDate}}

I have attempted to use the same smart value for a date custom field in Jira automation, but the field remains blank. 

How can I publish the same value to a date custom field? 

[Chris Rogers]

Hi @Brian Preuss

I've found that Jira can be a bit finicky depending on the date format and not all date formats are the same.

Since you're able to successfully put the date into a comment, you can try something like:

{{fixVersions.releaseDate.jiraDate}}

A list of the available date formats you can convert to is available here:

Jira smart values - date and time 

[Brian Preuss]

Hi @Chris Rogers 

Thank you very much! That solution worked!

I was able to get the value to populate - with a caveat. It seems that Jira is adjusting for my time zone (not sure if it is my Jira time zone or computer time) which is forcing the date to appear 1 day off. For example, the Fix Version release date is Jan 1, 2026, but the date added to the field is Dec 31, 2025.

My time zone is UTC-6. Here are the results. 

{{fixVersions.releaseDate}} = Thu Jan 01 00:00:00 UTC 2026
{{fixVersions.releaseDate.jiraDate}} = 2025-12-31

Do you have any tricks to deal with this?

[David Nickell]

Hello -- @Chris Rogers  - Good documentaiton link!

@Brian Preuss  - Can you use one of the timezone conversion functions in the documentation provided?

My "value add" here ---

1. keep in mind one Jira Work Item can have many FIx Versions.  I'd be interested in the use case and how the multiple versions impact it.
2. FixVersion dates might change.  I mean, we don't always ship on time - Right? 
3. Also items come and go from a release.  What happens if you set this custom field and then the item drops out?

Here is my REST display of a work item with 3 fixVersions as illustration.  There are many ways to use the relationship of Work Item to Fix Version without introducing a snapshot in time you have to manage going forward.

https://splitdimedata.atlassian.net/rest/api/3/issue/DEV-7?

{
  "expand": "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations,customfield_10210.cmdb.label,customfield_10210.cmdb.objectKey,customfield_10210.cmdb.attributes,customfield_10010.requestTypePractice",
  "id": "10503",
  "self": "https://splitdimedata.atlassian.net/rest/api/3/issue/10503",
  "key": "DEV-7",
  "fields": {
    "statuscategorychangedate": "2025-07-22T05:46:55.131-0400",
    "customfield_10110": null,
    "fixVersions": [
      {
        "self": "https://splitdimedata.atlassian.net/rest/api/3/version/10000",
        "id": "10000",
        "description": "And So It Begins",
        "name": "Go Live July 7",
        "archived": false,
        "released": false,
        "releaseDate": "2025-07-07"
      },
      {
        "self": "https://splitdimedata.atlassian.net/rest/api/3/version/10001",
        "id": "10001",
        "description": "Addressing specific reporting needs",
        "name": "Feature Release Aug 1 2025",
        "archived": false,
        "released": false,
        "releaseDate": "2025-08-01"
      },
      {
        "self": "https://splitdimedata.atlassian.net/rest/api/3/version/10066",
        "id": "10066",
        "description": "",
        "name": "December 2025 Emergency",
        "archived": false,
        "released": false,
        "releaseDate": "2025-12-25"
      }
    ],
    "statusCategory": {
      "self": "https://splitdimedata.atlassian.net/rest/api/3/statuscategory/2",
      "id": 2,
      "key": "new",
      "colorName": "blue-gray",
      "name": "To Do"
    },

[Chris Rogers]

As @David Nickell mentioned above, you can use some of the time zone functions to make that conversion, something like:

{{fixVersions.releaseDate.jiraDate.convertToTimeZone("America/Chicago")}}

The list of supported time zones is linked off of the page above (see Java time zones)

I find it easiest to play with the date conversion until you've got it right in audit log actions or a test issue and then lock it in when it's right.

[David Nickell]

Hello again.  I think you are getting good information on Date Handling in Automation. I'm not trying to necessarily spin up a new answer for the sake of having a new answer, but as I mentoned in my comments above, I think you have a real "why would you do this" question looming.

• Since there can be multiple versions on the item, I include some date description in the actual fix Version / Release name.  If the Release date changes, I just change the name and the actual date that goes with it
• And then the other points realitive to maintenance of a "field" when the date may change or the scope of the release may no longer include the work item in question.
• Added to that bullet above, the last thing you want is confusion about when an item is going to shift should your special date field and the actual release date aren't in synch.
• You may be using automation executions for this purpose.
• And any seasoned Admin will tell you, the more custom fields you have, the slower your performance tends to be.

Sorry to kick the proverbial "dead horse".  But since the discussion is still ongoing, I wanted to get a second shout-out to see why this new field is needed.

Thanks

[Thomas Anderson]

You can read the release date with fixVersions.releaseDate, but Jira Automation won’t write it to a date field unless you format it exactly the way Jira expects. Date fields require a strict yyyy-MM-dd format. Use something like {{fixVersions.releaseDate.format yyyy-MM-dd }} when setting the custom field. Once formatted, the automation will populate the date field correctly.