Journey details page unable to handle date formatsDescriptionWhen date format is changed from sys_user record, say, from system yyyy-mm-dd to dd-mm-yyy, then, tasks are being wrongly labelled as overdueSteps to Reproduce When date format is changed from sys_user record, say, from system yyyy-mm-dd to dd-mm-yyy, then, tasks are being wrongly labelled as overdueExample: Original date is 2023-06-01 (June 1st 2023) As of May 4th (today), the tasks with due date June 1th is not overdue.When date format is changes to dd-mm-yyyy then the date is interpreted as Jan 6th 2023 and the task is being labelled as overdue task (for may 4th as today)Defect created as part CSTASK564598/CS66453991. Create or modify Journey records with JA tasks with due date June 1st 20231.1. For journey owner change the date format from sys_user record2. Impersonate as user 3. Open https://<instance>/esc?id=jny_journey_details&sys_id=<journey sysid>4. Notice tasks with due date June 1st are marked as overdue and interpreted as Jan 6thWorkaroundWhen date format is changed for a user, say from system yyyy-mm-dd to dd-mm-yyy, the label on task cards is being miscalculated as overdue. Example: Original date is 2023-06-01 (June 1st 2023) As of May 4th (today), the tasks with due date June 1th is not overdue. But with date format changed, it was interpreted as January 6th. Similar issue is observed when timezones are changed. Example: When a task is due on May 18th, it would be displayed as an 'overdue' task in Indian time zone with current date as May 19th. This issue is fixed by considering local time while displaying these labels. Made following changes in ja_PlanUtilsSNC - #1289 - task.due_date_original = dueUpdateTime.getLocalDate().getValue(); This is will retrieve non-formatted date with local time zone. In function _setDueDateLabel() - use above value to calculate label #1331 - var dueDate = task.due_date_original; Also, get Today's date in local time zone to compare against. #1337 - var convertedToday = new GlideDateTime(new GlideDateTime().getLocalDate().getValue() + ' 00:00:00') Related Problem: PRB1664183