fix: time badge wrong for offset #3329
Open
+72 −20
Conversation
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
1 participant
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.
What is this PR about?
Problem:
The TimeBadge component was always displaying UTC+00:00 regardless of the actual server timezone.
The client was calculating the offset by converting dates to strings using
toLocaleString, then parsing those strings back into Date objects. When JavaScript parses a date string like "1/15/2025, 9:00:00 AM" withnew Date(), it interprets it in the browser's local timezone, not the intended timezone. Both dates ended up in the same timezone, so the offset was always zero.Fix:
I moved the offset calculation to the server side. The server now returns the offset along with the timezone and time. We use
Intl.DateTimeFormat.Extracted the offset calculation logic to
utils/time.tsasgetUtcOffset(timeZone)with comprehensive tests covering various timezones including edge cases like half-hour offsets (India UTC+05:30), invalid inputs, and the UTC special case.Issues related (if applicable)
closes #3328