UI: fix usage records end date with local timezone

[Dogface2k]

Description

This PR fixes the Usage Records date range when the user enables the local-timezone preference.

UsageRecords.getParams correctly used the first selected date for startdate, but also used that same first element for enddate in 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 enddate now uses dateRange[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

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

Not applicable.

How Has This Been Tested?

Validation results:

UsageRecords.spec.js
Tests: 3 passed, 3 total

Complete UI unit suite
Test Suites: 5 passed, 5 total
Tests: 178 passed, 178 total

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/London so 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 enddate expression. The complete UI unit suite, lint, production build, and git diff --check all pass.

[Copilot]

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 enddate generation to use dateRange[1] (selected end date) instead of dateRange[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]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 17.70%. Comparing base (5328528) to head (9d2db7d).

Additional details and impacted files

@@            Coverage Diff            @@
##               4.22   #13769   +/-   ##
=========================================
  Coverage     17.69%   17.70%           
+ Complexity    15835    15832    -3     
=========================================
  Files          5925     5925           
  Lines        533539   533539           
  Branches      65274    65274           
=========================================
+ Hits          94427    94448   +21     
+ Misses       428435   428410   -25     
- Partials      10677    10681    +4     

Flag	Coverage Δ
uitests	3.76% <ø> (+0.07%)	⬆️
unittests	18.77% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Dogface2k]

Follow-up commit 9d2db7d requires a complete two-value date range before generating startdate/enddate. Empty and partially selected ranges now omit both parameters, with focused tests covering each case.

[DaanHoogland]

@blueorangutan package

[blueorangutan]

@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 18767