Skip to content

fix(customParseFormat): preserve years below 100 - #3214

Open
sridharkalaibala wants to merge 1 commit into
iamkun:devfrom
sridharkalaibala:fix/custom-parse-format-low-years
Open

sridharkalaibala wants to merge 1 commit into
iamkun:devfrom
sridharkalaibala:fix/custom-parse-format-low-years

Conversation

@sridharkalaibala

@sridharkalaibala sridharkalaibala commented Sep 12, 2026 •

Copy link
Copy Markdown

Custom-format parsing currently turns 0002-08-01 into 1902-08-01, while strict parsing rejects it. Year zero is also treated as a missing year. These conversions affect controlled date inputs that pass through low years while the user edits the year, as reported in decaporg/decap-cms#7939.

Preserve explicit years 0–99 in local, UTC, and offset parsing. Construct in the corresponding year one Gregorian cycle later, then subtract that cycle from the normalized result. This preserves leap days and month/offset rollovers; the existing YY century convention stays unchanged. Distinguish an absent year from year zero when selecting defaults.

This targets the custom-format parser. Existing PRs #1862 and #2551 change the separate core parser; #2076 concerns years longer than four digits.

Validation:

  • Added 16 tests covering strict local/UTC round trips, year-zero defaults, leap days, offset crossings, overflow, and the YY convention. Before the fix: 14 failed, 2 passed.
  • Full suite: 810 tests across 94 suites pass, including the configured 100% line-coverage threshold.
  • Custom-parser and timezone suites: 133 tests pass under Pacific/Auckland, Europe/London, Europe/Paris, and America/New_York. Under America/Whitehorse the parser tests pass; four existing timezone-plugin DST tests fail identically on unchanged upstream code.
  • Both changed files pass ESLint. Whole-tree ESLint passes with only linebreak-style disabled for the Windows checkout; unmodified files otherwise report CRLF errors.
  • Built the plugin with the repository's Rollup/Babel/Terser configuration (one minifier worker). Temporarily loaded that bundle into Decap's installed Day.js 1.11.18: all 11 date-widget tests pass, including four regressions that fail with the original plugin. Restored the installed plugin afterward. Decap still needs a dependency integration after release.
  • Native keyboard check in Chromium: bundled the actual Decap DateTimeControl in a controlled React harness (only button styles stubbed). Starting from 2025-08-01, selected the year using Tab/Right/Right and pressed 2, 0, 2, 6 separately. With the original Day.js 1.11.18 plugin, the stored date ends at 1906-08-01; with the built patched plugin it progresses through 0002-08-01, 0020-08-01, 0202-08-01, and 2026-08-01. Both the visible input and stored value agree. This verifies the reported native year-entry failure and its correction in the widget harness; a full CMS integration was not run.

Developed and validated with OpenAI Codex assistance.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant