Repository navigation
Fix arithmetic with UTC timezone objects - #150
Merged
knowledgecode merged 2 commits intoOct 28, 2026
Merged
knowledgecode merged 2 commits into
knowledgecode merged 2 commits into
Conversation
Use the normalized timezone name when selecting UTC calendar setters. This keeps UTC objects consistent with UTC strings for days, month-end clamping, and leap-year arithmetic. Add isolated host-timezone regressions for DST, subtraction, UTC casing, immutability, and non-UTC object controls. Signed-off-by: Mayank Dhingra <mayankdhingra02@gmail.com>
knowledgecode
self-requested a review
October 27, 2026 11:20
knowledgecode
left a comment
Owner
There was a problem hiding this comment.
@mayankdhingra02 Thanks for the PR. I was able to reproduce it: because the inner branch checked timeZone instead of zoneName, a zone_name: 'UTC' object fell through to local-time arithmetic. I'd like to take the src/ changes as they are.
For context, none of the TimeZone objects shipped with the library is UTC, and passing timezone objects is deprecated in favor of strings ('UTC' is the recommended form for UTC).
I'd like the tests to follow the repository's conventions. Which would you prefer?
- You update the tests. Add the cases to the existing
UTC Timeblocks intests/addDays.spec.tsand the other affected spec files, and set the host time zone withprocess.env.TZinbeforeAllas the existing tests do (no child processes needed). One or two cases per function that fail before the fix are enough. I'll merge once the update is in. - If you only need the fix merged. I'll merge as is and rewrite the tests myself.
Move one regression per arithmetic function into its existing UTC Time block and select the host timezone with the usual beforeAll convention. Cover daylight-saving, month-end and leap-day arithmetic. Signed-off-by: Mayank Dhingra <mayankdhingra02@gmail.com>
knowledgecode
approved these changes
Oct 28, 2026
knowledgecode
left a comment
Owner
There was a problem hiding this comment.
Thanks for updating the tests! LGTM.
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.
Passing a UTC
TimeZoneobject currently uses the host's local calendarsetters, while the equivalent
'UTC'string uses UTC setters. On a LosAngeles host, for example:
Use the normalized zone name when choosing UTC arithmetic in
addDaysandaddMonths;addYearsdelegates toaddMonths. PassingTimeZoneobjectsis deprecated in favor of strings, and
'UTC'is the recommended form forUTC. The timezone objects shipped with the library do not include UTC.
One regression per function lives in its existing
UTC Timeblock, usingprocess.env.TZinbeforeAllto select a Los Angeles host, following therepository's test conventions. The cases cover the daylight-saving
transition, month-end clamping and leap-day clamping. All three fail on the
unchanged base and pass with the source fix.
Validation: lint, TypeScript checking, build and the full 2,331-test suite
pass on Node 22.23.4, 24.22.1 and 26.12.1. Coverage also passes on Node 26.
Vitest runs were limited to two workers.