UI: fix usage records end date with local timezone - #13769
Open
Dogface2k wants to merge 2 commits into
Open
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes an issue in the UI Usage Records date-range query parameter generation when the “use local timezone” preference is enabled, ensuring multi-day ranges correctly use the selected end date.
Changes:
- Corrects local-timezone
enddategeneration to usedateRange[1](selected end date) instead ofdateRange[0]. - Adds unit tests covering multi-day ranges, DST boundary behavior, and the non-local-timezone control path.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| ui/src/views/infra/UsageRecords.vue | Fixes enddate calculation in the browser-timezone conversion branch to use the selected end date. |
| ui/tests/unit/views/infra/UsageRecords.spec.js | Adds regression tests to validate correct UTC conversion across multi-day and DST-crossing ranges. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.22 #13769 +/- ##
=========================================
Coverage 17.69% 17.70%
Complexity 15835 15835
=========================================
Files 5925 5925
Lines 533539 533539
Branches 65274 65274
=========================================
+ Hits 94427 94457 +30
+ Misses 428435 428400 -35
- Partials 10677 10682 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This PR fixes the Usage Records date range when the user enables the local-timezone preference.
UsageRecords.getParamscorrectly used the first selected date forstartdate, but also used that same first element forenddatein the local-timezone branch. Any multi-day selection was therefore reduced to the first day after conversion to UTC. The non-local-timezone branch already used the selected end date correctly.The local-timezone
enddatenow usesdateRange[1]. No API parameters, timezone-conversion behavior, pagination, or unrelated UI paths are changed.A focused regression test covers a multi-day range with a non-zero UTC offset, a range crossing a daylight-saving transition, and the existing local-timezone-disabled behavior.
Fixes #13581
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
Not applicable.
How Has This Been Tested?
Validation results:
The UI lint completed with no errors, and the production UI build completed successfully using the repository's pinned Node 16.20.2 runtime.
The request windows were also checked read-only against a CloudStack 4.22.1 environment. For a selected eight-day range, the valid unconverted and correctly converted windows each returned 2,800 records; the original one-day window produced by the wrong index returned zero records.
How did you try to break this feature and the system with this change?
The regression test uses
Europe/Londonso the expected UTC values have a non-zero offset. A second range crosses the 2026 spring daylight-saving boundary to verify that the selected end date and its own offset are both used. The local-timezone-disabled branch is retained as a control to prove its existing start and end dates are unchanged.The production diff changes only the array index used by the local-timezone
enddateexpression. The complete UI unit suite, lint, production build, andgit diff --checkall pass.