Skip to content

fix: fall back to global 1904 windowing when @DateTimeFormat default is used (#1042) - #1054

Open
Mikkey-f wants to merge 2 commits into
apache:mainfrom
Mikkey-f:feat/1042-preserve-global-1904
Open

fix: fall back to global 1904 windowing when @DateTimeFormat default is used (#1042)#1054
Mikkey-f wants to merge 2 commits into
apache:mainfrom
Mikkey-f:feat/1042-preserve-global-1904

Conversation

@Mikkey-f

Copy link
Copy Markdown
Contributor

Summary

Fixes #1042. When a field carries @DateTimeFormat for the pattern only, its use1904windowing is left at BooleanEnum.DEFAULT; DateTimeFormatProperty.build() collapsed that to false, so the global 1904 windowing setting (builder option or workbook flag) was silently bypassed and date-number cells were interpreted with the 1900 windowing system, shifting dates by 1462 days (4 years).

Changes

  • DateTimeFormatProperty.build(): preserve DEFAULT as null instead of collapsing it to false
  • New shared helper DateUtils.resolveUse1904windowing(contentProperty, globalConfiguration): explicit annotation value wins, otherwise fall back to the global configuration (null-safe, defaults to false)
  • DateNumberConverter, LocalDateNumberConverter, LocalDateTimeNumberConverter, LocalTimeNumberConverter, StringNumberConverter: use the shared helper on both read and write paths
  • TimestampNumberConverter test fixture and the custom-converter example in core-class.md (EN/zh-CN) updated to the new helper, since they previously unboxed the property value directly

Testing

  • New unit tests: DateTimeFormatPropertyTest (DEFAULT/TRUE/FALSE preserved), per-converter regression tests covering annotation-default + global 1904 → follows global; explicit annotation → annotation wins
  • New end-to-end regression test DateTimeFormatDefaultWindowingTest replicating the issue's reproduction steps: on the pre-fix code it fails with expected: <2026-08-28T10:30> but was: <2022-08-27T10:30> (the exact 4-year shift from the issue); on the fixed code it passes
  • Full suite: 913/913 green, spotless and javadoc pass

Note

Verified empirically that the write path already followed the global setting before this change (the write API consumes the annotation's use1904windowing only via the shared converters). The write-path test is kept as an invariant guard rather than a bug regression test. OffsetDateTime/ZonedDateTime converters on #1033 already implement the same fallback pattern and are unaffected.

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.

[Bug] @DateTimeFormat use1904windowing DEFAULT is collapsed to false, bypassing the global 1904 fallback

1 participant