Fix tracking date selection for all timezones

[leodyversemilla07]

Summary

Properly converts stored dates from system timezone to UTC before comparison to fix date validation issues in positive timezones while maintaining the fix for negative timezones from PR #2617.

Issue

Fixes #3126

Root Cause

The previous fix (PR #2617) resolved date selection issues for negative timezones but inadvertently broke positive timezones.

Stored dates are in system local timezone, but the comparison logic was treating them as UTC timestamps without proper conversion:

In positive timezones (GMT+2):

• Stored: March 24 00:00 GMT+2 = March 23 22:00 UTC
• Code treated it as: March 24 00:00 UTC ❌
• Result: Date comparisons fail, users can't select same start/end date

In negative timezones (GMT-5):

• Stored: March 24 00:00 GMT-5 = March 24 05:00 UTC
• Code treated it as: March 24 00:00 UTC ❌
• Result: Happened to work due to both being on same day

Solution

Apply the same timezone conversion used for initialSelection (line 538) to the date comparison logic. This ensures stored dates are properly converted from system timezone to UTC before comparing with the picker's UTC timestamps.

Changed lines:

• Line 457-459: Convert track.finishDate from system timezone to UTC
• Line 462-464: Convert track.startDate from system timezone to UTC
• Line 478-480: Convert track.finishDate from system timezone to UTC
• Line 483-485: Convert track.startDate from system timezone to UTC

Testing

Manual testing recommended for both positive and negative timezones:

1. GMT+2: Should allow selecting same start/end date
2. GMT+2: Should prevent selecting end date before start date
3. GMT-5: Should continue working as before (regression test)
4. GMT-5: Should allow same start/end date

Self-review

• Consistent timezone handling across all date operations
• No visual changes
• Minimal code change, focused on the root cause