[Mikkey-f]

Purpose of the pull request

Closed: #1334

OffsetDateTimeDateConverter writes DATE cells that contain only the local date-time. A CSV file therefore contained yyyy-MM-dd HH:mm:ss without an offset, and reading it back into a plain OffsetDateTime field failed in OffsetDateTimeStringConverter, whose default parser is strict ISO_OFFSET_DATE_TIME.

What's changed?

• OffsetDateTimeDateConverter now overrides convertToExcelData(WriteConverterContext) and, for CSV without an explicit @DateTimeFormat, writes an ISO-8601 string with the offset (ISO_OFFSET_DATE_TIME). The value is read back unchanged by the existing strict OffsetDateTimeStringConverter. This follows the second option in [Bug] OffsetDateTimeDateConverter drops the offset and its CSV output cannot be read back #1334 (write an ISO string that carries the offset) and keeps the read side strict.
• XLSX and XLS keep writing DATE cells; those cells store only a local date-time, so the offset is still discarded. The javadoc documents this limitation.
• A configured @DateTimeFormat keeps the existing DATE-cell behavior on CSV; use OffsetDateTimeStringConverter when a custom representation must carry the offset.
• OffsetDateTimeStringConverter and DateUtils are unchanged; parsing stays strict, as requested in feat: add ZonedDateTime converters #1020.
• Added round-trip tests: CSV preserves the offset, XLSX/XLS read back the local date-time with the JVM default zone.

Verification:

• Targeted OffsetDateTimeConverterTest + OffsetDateTimeDateRoundTripTest: 14 + 3 passed.
• Reverting the write-side change reproduces the CSV failure (ExcelDataConvertException); the XLSX/XLS cases still pass without it.
• Full suite: fesod-common 60 + fesod-sheet 1,820, 0 failures / 0 errors / 0 skipped.
• spotless:check and javadoc:javadoc pass.

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

[vlamogulis]

Thanks @Mikkey-f for the clear reproduction steps. This one is easy to verify. I pulled the branch and ran a small standalone probe locally on Windows 10 Pro with Microsoft OpenJDK 21.0.10. Everything compiles and runs cleanly on my side.

On the branch without this change, the CSV contains 2024-01-02 03:04:05 and reading it back into an OffsetDateTime field fails with ExcelDataConvertException. On this branch the same probe writes 2024-01-02T03:04:05-05:00 and reads back the original value. An XLSX DATE cell still reads back as 2024-01-02T03:04:05+08:00, which matches the limitation documented in the converter.

I ran into a closely related limitation in an earlier PR of mine. An Excel numeric date cell carries no locale information, so a write then read round trip only reconstructs the wall clock value, and localized text appears only where the value is rendered as a string.

The same root cause shows up here with the offset. The value carries its offset when it is written, but an Excel DATE cell has nowhere to record it. On the read side the offset is either lost or replaced with the system default zone.

I agree with the direction in this PR. When the offset needs to survive, a string representation is the way to go. Keeping the read side strict, documenting the DATE cell limitation, and making the default CSV output readable back all look right to me.

LGTM from my side.