Issue Summary

Active sprints page shows incorrect time for Start/End sprint date/time.
* Creating a sprint during a DST date will result in all date/times indicated for Start/End that are outside DST getting an hour subtracted when viewed in the Active sprints.
* Creating a sprint out of a DST date will result in all date/times indicated for Start/End that are inside DST getting an hour added when viewed in the Active sprints.
 

Steps to Reproduce

1. Set your timezone to GMT+1 (although it can be any timezone that employs DST).
2. Go to a board's backlog to create a sprint, and configure it to start/finish on a date between the start and end of Daylight Saving Time (Sun, Mar 26, 2023 – Sun, Oct 29, 2023), in this example it's Oct 17, 2023, 12:00 PM :
3. Go to the Active sprints and hover your mouse over the time remaining for the sprint, on the top right side of the screen:

Expected Results

The date/time matches the ones indicated when creating/editing the sprint from the backlog.

Actual Results

The Active Sprints page shows 1 hour ahead of the data indicated in the Backlog: From our example, it shows 1 PM instead of 12PM. Note that the End date appears correctly as this date is out of DST, and it was also indicated while the user did this on November 10th, 2023, a date out of DST.

Notes:

• All dates we see in Jira are according to the time zone we have selected in our Atlassian Account, and whenever we enter a date in a Jira field, this will be saved into the database and converted to GMT. For example, if our time zone is GMT+1, and we save the date as 17 Oct, 2023 12:00 AM, in the database it is saved as 16 Oct, 2023 11:00 PM (one hour less). This is designed to allow everyone around the world with different time zones to see the dates adjusted to their own time zone.
• A large portion of Europe is normally in GMT+1, and during Daylight saving time, it is in GMT+2. This is relevant for our case, because Europe was in DST until Oct 29 2023, and this means that if our user has set their timezone to a place like Amsterdam or Rome, before DST ends is GMT+2, and after DST ends is GMT+1. 
• It is not clear if the issue is in the way the Backlog saves or displays the data, or if the Active backlog page is compensating incorrectly. 

Workaround

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