Burndown/burnup chart does not correctly reflect close date on an issue owing to timezone overlap with midnight
Summary
Burndown and burnup charts track the closure date and time on issues using resource_state_events.created_at WHERE state=2
The graphs will show a milestone as incomplete (not all issues closed during the milestone) if this datestamp is in the day after the end of the milestone, even if only by a fraction of a second.
Customer raised a ticket because the API and web UI show all issues in a milestone were closed on the last day of the milestone.
However, the charts didn't show this:
Looking at the data, one issue's close datestamp (in the API output) was:
"closed_at": "2023-02-07T23:11:29.176-03:00"And in the UI:
Note: -03:00 offset from UTC/GMT
Looking at the database records, they're recording it as the following day. (The fields are 'with time zone' but it's not obvious to me how this is depicted when querying them .. they show as +00 rather than, say, -03)
resource_state_events.created_at
-------------------------------
2023-02-08 02:11:29.288758+00
issues.closed_at
-------------------------------
2023-02-08 02:11:29.176837+00It appears that the offset from UTC means the burndown chart reads this issue as closed after the end of the milestone:
The datestamp in the JSON supplied by the customer indicates it was closed 49 minutes before midnight in a timezone three hours behind UTC, thus the database is recording it as 2 hours 11 minutes after midnight.
I have verified the customer's self-managed instance (currently running 15.3.3) matches our reference schema:
-
resource_state_events.created_atis typetimestamp with time zone(structure.sql, 15.3.3) -
issues.closed_atis typetimestamp with time zone(structure.sql, 15.3.3)
Steps to reproduce
Close issues in a milestone within 'x' hours of 23:59 on the last day of the milestone, where 'x' is your local timezone offset from UTC. This will likely be easier in western hemisphere timezones such as east-coast, mountain time, west coast etc. which are offset -x hours from UTC.
Example Project
What is the current bug behavior?
The GitLab user interface (web interface, API) shows that these issues were closed on the right day - during the milestone - but the burn down chart doesn't reflect this.
What is the expected correct behavior?
The burndown/burn up charts reflect the datestamps displayed in the rest of the product.
Relevant logs and/or screenshots
Output of checks
15.3.3 self managed