Skip to content

Fix arithmetic with UTC timezone objects - #150

Merged
knowledgecode merged 2 commits into
knowledgecode:masterfrom
mayankdhingra02:fix-utc-timezone-object-arithmetic
Oct 28, 2026
Merged

knowledgecode merged 2 commits into
knowledgecode:masterfrom
mayankdhingra02:fix-utc-timezone-object-arithmetic

Conversation

@mayankdhingra02

@mayankdhingra02 mayankdhingra02 commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Passing a UTC TimeZone object currently uses the host's local calendar
setters, while the equivalent 'UTC' string uses UTC setters. On a Los
Angeles host, for example:

addMonths(new Date('2025-01-31T00:30:00Z'), 1, {
  zone_name: 'UTC',
  gmt_offset: [0]
});
// Before: 2025-03-01T00:30:00.000Z
// After:  2025-02-28T00:30:00.000Z

Use the normalized zone name when choosing UTC arithmetic in addDays and
addMonths; addYears delegates to addMonths. Passing TimeZone objects
is deprecated in favor of strings, and 'UTC' is the recommended form for
UTC. The timezone objects shipped with the library do not include UTC.

One regression per function lives in its existing UTC Time block, using
process.env.TZ in beforeAll to select a Los Angeles host, following the
repository'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.

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
knowledgecode self-requested a review October 27, 2026 11:20

@knowledgecode knowledgecode left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

  1. You update the tests. Add the cases to the existing UTC Time blocks in tests/addDays.spec.ts and the other affected spec files, and set the host time zone with process.env.TZ in beforeAll as 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.
  2. 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 knowledgecode left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for updating the tests! LGTM.

@knowledgecode
knowledgecode merged commit 5c244df into knowledgecode:master Oct 28, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants