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

[Mikkey-f]

Search before asking

• I searched in the issues and found nothing similar. ([Bug] Unable to set use1904windowing when reading xlsx files #433/[Feature] supports setting setDate1904 when writing to xlsx files #434 cover the global read/write 1904 support and are unrelated to the annotation's DEFAULT semantics.)

Fesod version

2.0.2-incubating+ (current main)

JDK version

JDK 8+ (reproducible on any)

Operating system

Any

Steps To Reproduce

1. Create a POJO with a LocalDateTime (or Date) field annotated with @DateTimeFormat for the pattern only, leaving use1904windowing at its default:

public class DemoData {
    @ExcelProperty("time")
    @DateTimeFormat("yyyy-MM-dd HH:mm:ss")   // use1904windowing left at DEFAULT
    private LocalDateTime time;
}

2. Read a workbook whose date windowing is 1904, either by builder setting or by a file carrying the 1904 flag:

FesodSheet.read(path)
    .head(DemoData.class)
    .use1904windowing(true)   // global setting
    .sheet()
    .doReadSync();

3. Observe the parsed LocalDateTime — serial numbers are interpreted with the 1900 window (offset by 1462 days) instead of 1904.

Current Behavior

DateTimeFormatProperty.build() collapses the annotation's use1904windowing() default (BooleanEnum.DEFAULT = null) to false:

return new DateTimeFormatProperty(
        dateTimeFormat.value(),
        BooleanUtils.isTrue(dateTimeFormat.use1904windowing().getBooleanValue()));

So whenever a field carries @DateTimeFormat (even for the pattern only), the date-number converters consume false and the global use1904windowing setting is bypassed:

Path	1904 value used
No annotation	globalConfiguration.getUse1904windowing() (e.g. .use1904windowing(true) on the builder)
@DateTimeFormat with DEFAULT	false — global setting is bypassed
@DateTimeFormat(use1904windowing = TRUE/FALSE)	explicit value (correct)

The same POJO behaves differently on the read path (serial → date) and write path (date → serial) depending on whether the field happens to carry the annotation.

Expected Behavior

DEFAULT should keep its "user did not specify" semantics (as BooleanEnum's javadoc states — an enum "to determine whether the user has added the enumeration"). The converters should fall back to globalConfiguration.getUse1904windowing() when the property value is null, with the existing null-safe global default of false unchanged.

Suggested fix:

1. DateTimeFormatProperty.build(): pass use1904windowing().getBooleanValue() through as-is (keep DEFAULT as null)
2. Date-number converters (Date, LocalDate, LocalDateTime, LocalTime, ZonedDateTime, OffsetDateTime): when the property value is null, fall back to the global configuration — the OffsetDateTimeNumberConverter already implements this pattern
3. Regression test: @DateTimeFormat without use1904windowing + global .use1904windowing(true) → follows the global setting

Anything else?

Historical note from #433: GlobalConfiguration's use1904windowing = Boolean.FALSE default was introduced in 2021 to fix a test NPE — that null-safe global default stays untouched by this proposal.

Are you willing to submit a PR?

• I'm willing to submit a PR!

[alexsmolya]

I’ve been looking into this and have a focused approach in mind for the DEFAULT/global fallback behavior. If nobody is already working on it, I’d be happy to send a PR — but no problem if the issue author is already planning to handle it.

[Mikkey-f]

Thanks for checking, @alexsmolya — I'm planning to work on this one myself and will follow the approach in the issue description. Appreciate the offer!

[alexsmolya]

Thanks — understood. I had already finished an independent pass on this before I saw your note, so I’ve left the implementation in my fork as a reference:
alexsmolya@525ed95

The merge path is yours — no problem at all. The implementation, tests, and approach are simply there as open-source reference material. Please feel free to compare them, reuse anything useful, or ignore them if your approach works better.

[Mikkey-f]

Thanks for leaving the reference implementation in your fork — I've opened the PR following the same approach: #1054