The Test That Only Fails On The 31st
Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.
One test in the billing suite fails when CI happens to run in the last hour of the last day of a month. It passes on every developer machine. The team has re-run the pipeline twice and moved on.
Freezing time in the test: a library that patches the global clock plus a beforeEach that pins it to a fixed instant. The flake disappears immediately, no production code changes, and it is a well-known, well-supported technique — three good reasons it is what happens. What has been introduced is a global mutable setting that every other test now depends on nobody getting wrong: a suite that forgets to restore it fails an unrelated test in another file, execution order starts to matter, and parallel workers sharing a process share the patched clock. The original defect is untouched — computeBillingPeriod still cannot be asked about a date — so the first feature that needs a historical period reopens all of it.
Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.