Jasmine Clock Mocking or Manual Time-Zone Stubbing for Date Conversion

Direct Answer

Use direct Intl.DateTimeFormat stubbing per target zone and keep jasmine.clock() for controlling the flow of time. Do not rely on a manual offset applied to the mocked clock, and do not disable the clock entirely. A manual offset changes only the Date values returned by the mock; it does not change the time zone that Intl resolves from the host environment, so formatted output will still vary by region. Disabling jasmine.clock() removes deterministic control over relative dates such as "next week" or "expires in 30 minutes," which most date-conversion logic needs.

Why Manual Offsets Fail

When jasmine.clock().install() is active, the global Date constructor is replaced, but Intl.DateTimeFormat().resolvedOptions().timeZone continues to report the host machine's zone. If your production code formats a date with Intl.DateTimeFormat, the formatter reads the host zone, not the mocked clock's offset. The result is a spec that passes on a developer laptop in one region and fails in CI or on a colleague's machine in another.

Recommended Pattern

Stub Intl.DateTimeFormat for the specific zone under test, and restore it after the suite. This keeps the mocked Date and the formatter aligned on the same zone. The example below shows a scoped helper that avoids leaking the stub into unrelated specs.

// spec/helpers/intl-timezone-stub.js
let originalDateTimeFormat;

beforeEach(() => {
  originalDateTimeFormat = Intl.DateTimeFormat;
  Intl.DateTimeFormat = function (locale, options) {
    const fixedZone = 'America/New_York'; // set per suite
    return originalDateTimeFormat(locale, { ...options, timeZone: fixedZone });
  };
});

afterEach(() => {
  Intl.DateTimeFormat = originalDateTimeFormat;
});

Adjust the fixedZone value for each regional suite. Because the stub is installed in beforeEach and removed in afterEach, it does not affect other tests that rely on real locale data.

Verification

To confirm the behavior in your installed Jasmine release, run a minimal spec that installs the clock and logs the resolved zone:

it('shows the gap', () => {
  jasmine.clock().install();
  const zone = Intl.DateTimeFormat().resolvedOptions().timeZone;
  console.log('host zone:', zone);
  expect(zone).toBeDefined();
  jasmine.clock().uninstall();
});

Run the same spec on two machines with different TZ settings. If the logged zone changes while the mocked date stays fixed, the mismatch is confirmed. After adding the Intl stub, the formatted output should remain identical across both machines.

Uncertainty and Next Steps

Jasmine 4.x and 5.x do not document a clock offset parameter that also adjusts Intl. If your installed release happens to provide one, verify that it affects the resolved time zone before relying on it. Until that is confirmed, the Intl stub remains the reliable approach. If your specs also assert against Date.prototype.toLocaleString or similar methods, stub those explicitly as well, because they delegate to the same Intl machinery.

One diagnostic detail would change the recommendation: if your date-conversion code never calls Intl and only performs arithmetic on Date objects, then jasmine.clock() alone is sufficient and the Intl stub is unnecessary. If it does call Intl, the stub is required.