fix: inconsistent timezone handling in daily allocation aggregation #9888
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ticket
CM-440
Description
Our Historical Usage page fetches allocations by date in UTC time specifically, and we store allocations without a timezone, which converts the input time to UTC before storing the timestamp without the timezone internally.
However, fetching timestamps with no timezone and then casting to
timestamptz
(with a timezone) only adds a timezone to the stored time stamp, doing no internal conversion from UTC to the corresponding time in the user's set timezone. (so('2024-10-02 01:30'::timestamp)::timestamptz = 2024-10-02 01:30 <user_set_timezone>
, which isn't what we want.With the changes in this PR, we keep consistent with how allocations are stored and continue to handle them in the
resource_aggregates
table without casting to atimestamptz
.Test Plan
CI passes (automated testing).
Checklist
docs/release-notes/
See Release Note for details.