How to use local date in workflow date validator

[Reinhard Karbas]

We have a workflow validator to make sure the date used is the current date or later.
The comparison is done against now (date comparison JSU), using only the date part.
However, as Jira is using UTC and we are in the US as soon as UTC date changes to the next day the comparison for the same date will not work anymore as the UTC time has already changed.
Is there a way to configure now in the date validator to use local time?

[Trudy Claspill]

Hello @Reinhard Karbas 

Welcome to the Atlassian community.

Can you show us the details of the configuration of the validator please?

I don't have access to a DC instance with JSU at the moment. Just looking at the documentation for JSU for DC I'm not seeing how you can set up the Date Compare validator to compare to now(). It appears to be set up comparing two date fields, not a comparison between a date field and a relative date. Are you perhaps using the Date Expression Compare validator instead?

[Reinhard Karbas]

Yes, you are correct, it is the Date Expression Compare validator

[Reinhard Karbas]

Anyone having an idea how this could be addressed?

[Trudy Claspill]

I am sorry I could did not get back to you sooner. Work became very busy.

I was able to recreate the problem in a Jira DC 9.12.28 instance with JSU v2.49.0.

What version of Jira and JSU are you using?

To the best of my knowledge (dredging up old Jira DC knowledge) Jira stores all date/time fields in the database as UTC and converts them to the timezone of the user at display-time.

But I think fields that are Date only are stored simply as the date selected without consideration for timezone.

I experimented with changing my timezone setting from LosAngeles to UTC, setting a date field to "today" (31 Dec 2025 in UTC), and then reverting my timezone setting to LosAngeles where the current date is 30 Dec 2025. The Date only field data continued to display as 31 Dec 2025.

The expression now will always be UTC for the current date/time. It appears that in the context of this validator it is not converted to the user's timezone preference.

So if I set a date field to today what is stored in the database is the date I selected. Let us say that the UTC date/time is 30 Dec 2025 23:59 and I set a date field to 30 Dec 2025. That is the date that gets stored in the database.

Time keeps rolling on and in a few minutes the UTC date/time for now becomes 31 Dec 2025 00:10. The date stored in the date field is now no longer equal to or greater than now though it is still equal to or greater than my local date.

You could open a support request with the vendor of the app (Appfire) to ask if what I have hypothesized is actually true. And you could ask them if it is expected that in that validator now is not converted to the executing user's timezone before the comparison.

I did find that if I tried a JQL statement for 

dateField >= now()

...that does seem to convert now to the acting user's timezone. When I tried this, UTC date had become 31 Dec 2025 while my local date was still 30 Dec 2025. The query returned issues where the date field was set to 30 Dec 2025 and later.

I see in the latest JSU documentation that they show the option to have a JQL Validator. That doesn't appear to be available in the version of JSU that I have but perhaps it is in yours. Perhaps you can try that as an alternative. I think the JQL you would want to use is

key = {issue.key} and "PROD Target Deploy Date" >= now()

And the condition you would choose is "= 1" to ensure that 1 issue is returned by that JQL.

I'm not sure if now would be converted to the acting user's timezone in this context, but it is worth trying.