test: DST fuzzing (spec 3.6) + walker perf fix it surfaced#542
Merged
Conversation
Add seeded fuzz tests (spec 3.6): 3000 random expression x timezone x date cases that must always return a future instant, 10,000 chained getNextMatch calls that must stay strictly monotonic across DST, and impossible expressions that must fail in finite time. The RNG is seeded so any CI failure is reproducible. The fuzz surfaced a real performance cliff: a dense-time expression also constrained by day-of-month AND weekday (e.g. `* * * 15 * 1`) scanned all 86,400 times of day on every day that matched the day-of-month but not the weekday, taking ~5 minutes for a single getNextMatch. The walker now pre-checks the weekday (computed arithmetically, mirroring match()'s conversion) before the time-of-day scan, skipping those days outright.
getUTCDay() and the converted weekday field share the same 0-6 (Sunday=0) space, so the day-of-week pre-check needs no weekday-name array or weekDayNamesConversion round-trip.
The SF-/FB-/CN-/ST-/FZ- codes and 'spec 3.x' labels meant nothing in the test output; each test now reads as what it actually verifies.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR3 of the DST work (spec
05-spec-dst§3.6).Fuzz tests (seeded, reproducible)
expression × timezone × datecases —getNextMatchmust always return a timestamp strictly after the reference (or fail in finite time for impossible expressions).getNextMatchacross the NY DST transitions — strictly monotonic, never faster than the interval.0 0 31 2 *, etc.) fail in finite time (≤ the walk bound).FUZZ_SEEDto override), so a CI failure replays exactly.Real bug the fuzz found (and this PR fixes)
A dense-time expression also constrained by day-of-month AND weekday — e.g.
* * * 15 * 1(the 15th, only when it's a Monday) — took ~5 minutes (323,152ms) for a singlegetNextMatch.Cause: the walker pre-checked month + day-of-month before the time-of-day scan, but not the weekday. On every "15th that isn't a Monday" it scanned all 86,400 hour×minute×second combinations, materializing each instant and calling
match(), all rejected on weekday.Fix: the walker now pre-checks the weekday per day (computed arithmetically — a Y/M/D's weekday is timezone-independent — mirroring exactly the conversion
match()uses, so it only skips days that would be rejected anyway).* * * 15 * 1now resolves in <1s (regression test FZ-4).Result
314 tests green under both
TZ=UTCandTZ=America/Sao_Paulo. Fuzz runs in CI (via the existingnpm test).DST plan status
utcOffset(dropped)