When creating a new feature, setting the Start / Initiation Date and/or Target Completion Date in a Jira Align Feature fails if the user is not using US Date formats

XMLWordPrintable

      Issue Summary

      When using the Jira Align console with the browser set to use the UK/EMEA date format of DD/MM/YYYY (and not the US format of MM/DD/YYYY), if a user creates a new feature and sets the the Start / Initiation and/or Target Completion Dates before the first save, then on clicking Save, somehow a US date format is applied and two invalid results can be seen:

      • If the numeric value entered for DD (in the DD/MM/YYYY format) is greater than 12, then the date will show as blank (because the US date format of MM/DD/YYYY does not expect a number greater than 12 to be present in the MM field)
      • If the numeric value entered for DD (in the DD/MM/YYYY format) is 12 or less, then the date after the save will show the date and month swapped over, for instance if you entered 09/07/2025 you will see 07/09/2025

      Steps to Reproduce

      1. Use a browser that is set for UK Language and Date formats.
      2. Use In a configuration with an existing capability that has a date range set by the Start / Initiation and/or Target Completion Dates fields (this may not be necessary but it is part of the steps from the reporting customer)
      3. Create a new feature connected to the capability (so same program, same PI etc) and before hitting save in that feature set both the Start / Initiation and Target Completion Dates fields so that the MM part of DD/MM/YYYY is greater than 12.
      4. Click Save and after the refresh the date fields will be empty
      5. Create a second new feature connected to the capability and before hitting save in that feature set both the Start / Initiation and Target Completion Dates fields so that the MM part of DD/MM/YYYY is 12 or less.
      6. Click Save and after the refresh the date fields will show that the month and day numeric values have been swapped around.
      7. If you then set similar dates but edit the existing feature instead of creating a new feature then the dates are saved correctly

      Note: A review of the audit logs during these steps shows that the date is recorded as YYYY-MM-DD in the audit log and seems to always report the correct dates even though the console shows different.

      Expected Results

      The date should save correctly no matter what date format is being used in the browser settings or if the action is either: create a new feature or edit an existing feature.

      Actual Results

      The date is not saved correctly when using a browser set to a UK/ European date format, when creating a new feature but is saved correctly when editing an existing feature.

      Workaround

      To avoid the issue, when creating a new feature, save the feature once before entering the dates, then set the dates and save the feature again.

      If the dates have already been set incorrectly then to correct them, just edit the dates and click save. Noting that if the completion date was set before the start date, you may have to delete both dates and click save before you can re-enter the correct dates and click save again.

            Assignee:
            Don Fuller
            Reporter:
            Colin Weaver (Inactive)
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: