CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/dst-transition-reference

Pure-reference catalog of Daylight Saving Time (DST) transition patterns and their canonical bug classes. Covers the spring-forward (skipped hour: 02:00 → 03:00 local) and fall-back (repeated hour: 02:00 → 01:00 local) transitions, the historical irregularity of DST (different jurisdictions, transitions on different dates, some regions abolish DST or never adopted it), the IANA timezone database (tz / Olson DB) as the canonical source, and the testable behaviors DST creates (duplicate / missing local timestamps, cron jobs that fire 0 or 2 times, billing periods that miss / double-count, recurring meetings on transition days). Per-jurisdiction DST-rule tables, refreshable per-region test-data fixtures, and the leap-second reference (23:59:60 insertion, time_t stalls, leap-smear vs step, monotonic-clock fixes) live in references/. Use when designing or auditing time-handling code or test cases, or when auditing leap-second assumptions.

68

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured reference skill: excellent progressive disclosure, concrete per-library behavior tables, and a clear usage sequence. Its main cost is token weight — it re-teaches DST basics Claude already knows and repeats the spring-forward example across sections, so it reads as a padded reference rather than a lean one.

Suggestions

Compress the "DST mechanics" section to the library-behaviour tables plus the two fixture timestamps, dropping the general explanation of what spring-forward/fall-back means — Claude already knows this.

Merge the "Worked example" into the testable-behaviours table (or reduce it to the assertion column) since it restates the transition facts and library results already given above.

Add one copy-paste assertion snippet (e.g. a 3-line Python zoneinfo test for 2026-03-08 02:30 America/New_York) so the worked example is executable rather than descriptive.

DimensionReasoningScore

Conciseness

Sections like "DST mechanics", "Duration arithmetic" and "Storage" re-explain well-known concepts (what spring-forward/fall-back means, that naive datetimes are undefined across DST, that local-string storage is unsafe) that Claude already knows, and the "Worked example" repeats the transition facts stated two sections earlier. Mostly efficient, but it could be tightened to a leaner bug-class/mitigation/test table.

3 / 5

Actionability

Concrete, near-executable guidance throughout: exact fixture timestamps ("2026-03-08 02:30 America/New_York"), per-library expected results ("zoneinfo normalises to 03:30 EDT", "pytz raises NonExistentTimeError"), and a testable-behaviours table mapping each behaviour to a specific test. Minor gap: assertions are described in prose rather than given as copy-paste code snippets.

4 / 5

Workflow Clarity

"How to use this reference" gives a clear 4-step sequence (identify transition → match bug class → turn into assertion → pick zones and refresh fixtures), and the "refresh them against IANA before each release" step plus the Limitations section act as staleness checkpoints. No feedback loop for the assertion-fails case, which keeps it below the top anchor.

4 / 5

Progressive Disclosure

The body is a genuine overview: mechanics, bug classes, and test table inline, with per-jurisdiction rules, fixtures, and leap-second detail correctly pushed to references/jurisdictions-and-fixtures.md, references/leap-seconds.md, and references/smear-strategies-and-history.md — all real files, directly linked, each with its scope stated. Navigation is one level deep and easy.

5 / 5

Total

16

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, highly specific description that clearly states what the catalog covers and when to use it, with well-chosen technical trigger terms. Its only weaknesses are mild: a few everyday synonyms ("daylight savings", "clock change") are absent, and at ~170 words it is near the upper bound of what a description should carry.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete capabilities: "spring-forward (skipped hour: 02:00 → 03:00 local) and fall-back (repeated hour: 02:00 → 01:00 local)", "IANA timezone database (tz / Olson DB) as the canonical source", "cron jobs that fire 0 or 2 times, billing periods that miss / double-count", plus leap-second coverage and the references/ bundle contents. Coverage is comprehensive with no generic filler; it is long but every clause carries information rather than padding.

5 / 5

Completeness

Explicitly answers both questions: what it is ("Pure-reference catalog of DST transition patterns and their canonical bug classes", with an enumerated scope list and bundle pointers) and when to use it ("Use when designing or auditing time-handling code or test cases, or when auditing leap-second assumptions"). Both halves are concrete and trigger-phrase-driven.

5 / 5

Trigger Term Quality

Strong natural terms users would say: "Daylight Saving Time (DST)", "spring-forward", "fall-back", "timezone", "cron jobs", "leap-second", "billing periods", "recurring meetings". A few common phrasings are missing — the everyday variant "daylight savings", "clock change", "time shift" — so it falls just short of the comprehensive-with-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (DST/leap-second transition edge cases) with distinct triggers like "spring-forward", "repeated hour", "23:59:60 insertion", "leap-smear vs step". Risk of firing for the wrong skill is minimal; adjacent skills (fake-clock-testing, timezone-test-matrix-builder) are consumers, not competitors.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents