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

Goal

Choose a consistent strategy for testing date-conversion logic that must behave identically across regional time zones.

Constraint

Jasmine's jasmine.clock() replaces the global Date constructor, but it does not alter the value returned by Intl.DateTimeFormat().resolvedOptions().timeZone. Code that formats dates using Intl therefore continues to use the host system's zone, while mocked Date values advance deterministically. This mismatch can make the same spec pass in one region and fail in another.

Jasmine 4.x and 5.x do not document a clock offset parameter (verify behavior for your installed release), so test authors must either extend the clock manually or stub Intl.DateTimeFormat separately. Adding a third-party time-zone library risks double-mocking Date and increases maintenance.

Questions

• Should regional date-conversion specs rely on a mocked clock with a manually applied offset, or on direct Intl.DateTimeFormat stubbing per zone?
• Is it preferable to disable jasmine.clock() for these tests and control time zone through the test environment instead?