Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Jira Automation – Error updating Target End date using Error parsing date string in field Target End

Karmandroid Singularity
Contributor
July 20, 2025

Hi everyone,

I'm using JIRA Data Center(Atlassian Jira Project Management Software (v9.12.17)) and trying to set up an automation rule in Jira, but I'm running into a date parsing issue.

Here are the relevant fields I'm working with:

Field NameTypeID / Source
Target StartTarget Startcustomfield_17971
Target EndTarget Endcustomfield_17972
Estimates (d)Numberissue.timetracking.remainingEstimateSeconds

Both Target Start and Target End are expected to be Date fields. However, they show as “Target Start” and “Target End” under the Type column, which makes me unsure if they’re actually treated as Date fields.

Screenshot 2025-07-20 174410.png

Screenshot 2025-07-20 175306.png

What I’m trying to do:

When the Estimate is updated and Target Start is not empty, I want to automatically set:

 

Target End = Target Start + Estimate (in workdays)

  

My smart value expressions:

Variable for workdays:

{{issue.timetracking.remainingEstimateSeconds.divide(28800).round}} 

Update JSON:

 


ALL OF FOLLOWING HAS THE ERROR:

{

"fields":
{ "customfield_17972": "{{issue.customfield_17971.plusBusinessDays(workdaysToAdd).jqlDate}}" } }

{
"fields":
{
"customfield_17972": "{{issue.customfield_17971.jiraDate.plusBusinessDays(4)}}"
}
}

{
"fields":
{
"customfield_17972": "{{issue.customfield_17971.plusBusinessDays(4)}}"
}
}

  


The problem:

I get the following error when the rule runs:

 

Error parsing date string: (customfield_17972)

I’ve verified that customfield_17971 (Target Start) is not empty during testing. Any idea why the .plusBusinessDays() or .jqlDate part is failing here?

Appreciate any help or clarification on this — especially if there’s a better way to format or update Date fields using smart values in automation!

Thanks!

 

UPDATE:

Tired another syntax as follow

WORKS!
------------------------------------
{
"fields": {
"customfield_17972": "{{issue.customfield_17971}}"
}
}

{
"fields": {
"customfield_17972": "2025-10-10"
}
}
---------------------------------------

DOESN'T WORKS (same error: Error parsing date string: (customfield_17972))
---------------------------------------
{
"fields": {
"customfield_17972": "{{issue.customfield_17971.plusBusinessDays(workdaysToAdd).format(\"yyyy-MM-dd\")}}"
}
}

{
"fields": {
"customfield_17972": "{{issue.customfield_17971.plusBusinessDays(workdaysToAdd.asNumber).format(\"yyyy-MM-dd\")}}"
}
}
---------------------------------------

 

And I noticed that this function:

plusBusinessDays()

Need an Integer for the parameter, so after reading this post: https://community.atlassian.com/forums/Jira-questions/Is-it-possible-to-use-a-smart-value-within-the-minusBusinessDays/qaq-p/1557511#U3072188

I tried to put log like this:

workdaysToAdd = {{workdaysToAdd}} \n
now = {{now}} \n
now format = {{now.format("yyyy-MM-dd")}} \n
issue.customfield_17971 = {{issue.customfield_17971}} \n
now.plusBusinessDays(1) = {{now.plusBusinessDays(1)}} \n
now.plusBusinessDays(1) format = {{now.plusBusinessDays(1).format("yyyy-MM-dd")}} \n
now.plusBusinessDays(workdaysToAdd) = {{now.plusBusinessDays(workdaysToAdd.asNumber)}} \n
now.plusBusinessDays({workdaysToAdd}) = {{now.plusBusinessDays({workdaysToAdd.asNumber})}}

Output as follow:

workdaysToAdd = 70 \n 
workdaysToAdd asNum = \n
now = 2025-07-20T16:11:20.5+0000 \n
now format = 2025-07-20 \n
issue.customfield_17971 = 2025-07-25 \n
now.plusBusinessDays(1) = 2025-07-21T16:11:20.5+0000 \n
now.plusBusinessDays(1) format = 2025-07-21 \n
now.plusBusinessDays(workdaysToAdd.asnumber) = \n
now.plusBusinessDays({workdaysToAdd}.asNumber) =

So, what I suspect this far:

  1. Smart value variables created using Create variable seem to be treated as Strings.

  2. .asNumber is not supported in my Jira environment, so I can’t force the type conversion.

  3. This may be causing plusBusinessDays(workdaysToAdd) to fail silently, since it's expecting a number but receiving a string.

 

Has anyone found a reliable way to pass a dynamic number (like estimate in days) into plusBusinessDays()?

Note: I still need to skip the weekend

1 answer

1 accepted

5 votes
Answer accepted
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 20, 2025

Hi @Karmandroid Singularity 

In Jira Cloud, Server, and Data Center automation, a Created Variable is always text / string, and must be converted for use as other types.  And...

You are using Jira Data Center, and thus for automation rules:

  • The asNumber function is not supported yet; here is a related suggestion which might add it: https://jira.atlassian.com/browse/JIRAAUTOSERVER-1084
  • Within the long-format of math expressions, date functions, etc., variables are automagically converted to numbers
  • When using inline math expressions, the left-most parameter's type determines what happens, and so your division of the time tracking seconds uses integer division.  Thus the round should not be needed...and for some cases, the result may return as 0 when expecting only a fractional result.
  • For Data Center, and based on community questions I have read, some date / time functions cannot be chained, and only experimentation will confirm what works (or not)
  • Finally, regarding silent failures: in rule logic, when something evaluates to null that often fails silently unless a value is specifically required.  For example, with dynamic JQL, dynamic JSON, an email address, etc.

 

Okay, back to your question: please try this expression with your variable, assuming it is an integer:

{{#now}}func=plusBusinessDays({{workdaysToAdd}}){{/}}

 

Kind regards,
Bill

Karmandroid Singularity
Contributor
July 20, 2025

Hi @Bill Sheboy 

I tried

{{#now}}func=plusBusinessDays({{workdaysToAdd}}){{/}}

2025-08-15T17:14:39.1+0000

When i tried:

{{#issue.customfield_17971}}func=plusBusinessDays({{workdaysToAdd}}){{/}}

it return:

func=plusBusinessDays(20)

also tried to define a variable to store 17971:

Screenshot 2025-07-21 003640.png

and call it like this:

{{#StartDate}}func=plusBusinessDays({{workdaysToAdd}}){{/}} 

it returns:

func=plusBusinessDays(20)

I will need to add the estimation day to my Target Start (customfield_17971) and assign the result to Target End (customfield_19792)

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 20, 2025

Within rules, the Target Start and Target End fields are text representing dates.  And so they must be converted first with toDate:

{{#issue.customfield_17971.toDate}}func=plusBusinessDays({{workdaysToAdd}}){{/}}

 

And when setting the field, it needs to be in jiraDate format.  So save the above value in a variable, perhaps named varTargetEnd, and then format it:

{{varTargetEnd.toDate.jiraDate}}

 

Karmandroid Singularity
Contributor
July 20, 2025

wow, it works! Thanks @Bill Sheboy 

Let me summary how:

  1. Create variable to store the additional days (workdaysToAdd)
    {{#=}}{{issue.timetracking.remainingEstimateSeconds}}/28800{{/}}
  2. Process the update(Edit Action) of the Target Date field using JSON as follow:
    {

    "fields":
    {
    "customfield_17972": "{{#issue.customfield_17971.toDate}}func=plusBusinessDays({{workdaysToAdd}}){{/}}"
    }

    }

     

Follow-up question:
How to make it works on Advance Roadmap? On Advance Roadmap when I edit the field i will need to review and confirm apply it before I can see the updated Target Date

Screenshot 2025-07-21 133141.png

Are there any way to make it real-time showing the updated Target Date when I change the Estimates (d) ?

Posted it here: https://community.atlassian.com/forums/Jira-questions/Apply-Automation-Rule-on-Advanced-Roadmap-JIRA/qaq-p/3072417#M1137861

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 21, 2025

No, I do not believe so.  Please see Walter's explanation in your other question.  Thanks!

Suggest an answer

Log in or Sign up to answer