zimFile.cy.js 'shows the next generation date' test is timezone-dependent

[audiodude]

The Cypress test the zim file creation page > ... > when there is an active schedule > shows the next generation date in wp1-frontend/cypress/e2e/zimFile.cy.js fails when run on a machine in a non-UTC timezone:

AssertionError: Timed out retrying after 4000ms: Expected to find content: 'June 1, 2026' but never did.

Cause: the fixture cypress/fixtures/zim_status_with_schedule.json contains a bare date string:

"next_generation_date": "2026-06-01"

JavaScript's new Date('2026-06-01') parses date-only strings as UTC midnight. When the frontend formats that with a locale date formatter, any browser west of UTC renders it as the previous day — e.g. "May 31, 2026" in America/Los_Angeles — and the assertion on the literal string "June 1, 2026" fails.

CI doesn't catch this because GitHub Actions runners are UTC. Verified both ways while working on #1191: the spec fails on a PDT machine and passes on the same machine with TZ=UTC ... cypress run --spec cypress/e2e/zimFile.cy.js (42/42).

Possible fixes (any one is sufficient):

• Parse the date as a local date in the frontend (e.g. split the YYYY-MM-DD string instead of letting Date interpret it as UTC) — this is arguably a real user-facing bug, since users west of UTC see their next generation date one day early.
• Pin the timezone in the test/spec run (TZ=UTC in the cypress script).
• Make the fixture an unambiguous timestamp and assert on a value computed with the same formatter.

The first option is the most thorough, since the displayed-date-off-by-one affects real users, not just tests.

🤖 Generated with Claude Code