## TL;DR
cy.clock() replaces the browser timers, and if nothing restores them, the next test inherits fake time. Always pair clock setup with a restore in an afterEach hook, or scope the clock to a single test and verify Date.now is real again afterwards. The leak usually hides in a shared beforeEach that installs the clock for every test.

## The query
```text
cypress clock() not restoring time after test: how to fix
```

## Use this when
- Tests pass alone but fail when run after a clock-using test
- Timeouts behave strangely in tests that follow timer mocking
- Date.now returns a frozen value in a test that never called cy.clock()

## Not for
- Mocking time on the server or in API tests
- Choosing between cy.clock and other time libraries
- Timezone handling

## Steps
1. Find every cy.clock() call. Search the spec files and support files for clock usage, including shared hooks.
   Expected output: a complete list of clock installs with their file and line.
2. Check for a matching restore. Each install needs a restore path, usually in afterEach. A clock installed in beforeEach without an afterEach restore leaks by design.
   Expected output: identification of the hook or test missing its restore.
3. Add the restore in afterEach. Restore timers even if the test failed, so one red test does not poison the rest of the run.
   Expected output: an afterEach hook that restores the clock, applied to the affected specs.
4. Verify time is real in the next test. Add a temporary assertion that Date.now advances between two reads in the test following the clock usage.
   Expected output: the temporary check passing, proving no leak, then removed.
5. Prefer scoping the clock to one test. Move cy.clock() out of shared hooks and into only the tests that need it.
   Expected output: clock calls only in tests that mock time, with the suite green in full runs.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ehXcOsVKrQcnXbrJAxwXXA