Issue Summary

As shown in the image above, the value for the Date 1 field is 16/Jun/23 in the Date picker field, but in the error message, it shows as 15/Jun/23 5:00 PM. This happens because we convert the output time into the user’s timezone. The user’s time zone (https://id.atlassian.com/manage-profile/account-preferences?ref=jira&src=personalsettings), in this case, to replicate the issue it is America/Phoenix (GMT -7).

Ideally, if the Date 1 (field being compared with) is a date picker, then the output time should be kept the same as the time value in the Date 1 field.

Steps to Reproduce

1. Set your timezone to "America/Phoenix" in your Account Preferences: https://id.atlassian.com/manage-profile/account-preferences?ref=jira&src=personalsettings
2. Create a transition screen and enter two date picker fields in it.
3. Create a transition from one status to another status.
4. Add two "Date compare validators" to this transition.
5. The first validator to check if the 1st field is greater than now or 0d. 
6. The second validator is to check if the 2nd field's date is less than the 1st field's date. Publish the workflow.

Expected Results

Ideally, if the Date 1 (field being compared with) is a date picker, then the output time should be kept the same as the time value in the Date 1 field.

Actual Results

1. Now when we will make the transition, then we will observe that if we fill the date in the 1st field less than "now" or "0d" then it will throw an error stating that the 1st field date is less than today's date. But this 1st field date will be shown as 1 day prior date than the date that you have set in this field in the error message. This is due to the Bug JRACLOUD-67444.
2. However, when we set the 2nd field's date to greater than the 1st field then we will get the error as expected stating that the 2nd field's date is greater than the 1st field as per the Date Compare validator. But in this error message as well the date of the 1st field is shown as 1 day prior date than the date that you have set in this 1st field. 

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available