[Sean-Walker0]

Purpose of the pull request

WorkBookUtil.fillDataFormat treated an empty pattern like a real one: a model field annotated with @DateTimeFormat("") had an empty custom format stored on the cell, which renders as General — so a LocalDateTime field showed the raw serial number 43832.12783564815 instead of a formatted date.

The OffsetDateTime converter already normalizes empty patterns (added with #1033), which made the identical annotation behave differently depending on the field type; the LocalDateTime/LocalDate/LocalTime/Date/SqlTime/Timestamp converters and the write-executor path all pass their format through unchanged and can hit the same hole.

No issue exists for this yet; found while auditing the converter families.

What's changed?

fillDataFormat now treats an empty pattern like an absent one and falls back to the supplied default format. One central change covers every date converter, the write-executor data-format path and future callers; the per-converter normalization #1033 introduced stays (now redundant but harmless).

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.

Verifying this change

EmptyDateTimeFormatWriteTest:

• localDateTimeWithEmptyFormatFallsBackToDefaultDateFormat — red before (expected: <yyyy-MM-dd HH:mm:ss> but was: <General>), green after;

• offsetDateTimeWithEmptyFormatFallsBackToDefaultDateFormat — pins the existing feat: add java.time.OffsetDateTime converters (#1017) #1033 normalization, green before and after;

• explicitFormatIsStillApplied — an explicit yyyy/MM/dd pattern is applied as-is, green before and after.

• ./mvnw clean package -B -Dmaven.test.skip=false -pl fesod-common,fesod-shaded,fesod-sheet: 1780 tests, 0 failures, 0 errors.

• ./mvnw -pl fesod-sheet spotless:check: clean.

Notes

• Behavior change: @DateTimeFormat("") (and any other empty-pattern source) now falls back to the default date format instead of storing an empty custom format that renders as General. Explicit patterns are untouched.
• Orthogonal to open PRs: no open PR touches WorkBookUtil or the date converters; my open fix(sheet): escape hex sequences in head and multi-variable fill cells #1226/fix(sheet): escape hex sequences in in-memory XLSX writes too #1223 (escape handling) and fix(sheet): tolerate a null rounding mode in the decimal format cache #1270 (rounding-mode NPE) touch unrelated regions.

[skytin1004]

Hi @Sean-Walker0, thanks for the fix. I checked the shared formatting change and its callers. An empty date format now correctly uses the default format, while an explicit format is still preserved.

I also ran the new XLSX integration tests and WorkBookUtilTest. All tests passed. Looks good to me!

[bengbengbalabalabeng]

The code here is quite self-explanatory. We might not need this comment, or we could consider removing it to keep the code clean.

[bengbengbalabalabeng]

• new FileInputStream(file) is passed anonymously, so Java's try-with-resources won't automatically close it, and POI does not close caller-supplied streams. It is recommended to use WorkbookFactory#create(File) directly instead, it eliminates resource leak risks and is much more memory-efficient.
• If the caller only needs cell.getCellStyle().getDataFormatString(), consider returning that String directly from this method. This prevents callers from holding a Cell object tied to an already-closed Workbook, which could lead to unexpected runtime exceptions.

[bengbengbalabalabeng]

Consider importing org.apache.fesod.sheet.testkit.enums.ExcelFormat to avoid using the FQCN here.

[Sean-Walker0]

All three points addressed and force-pushed:

1. Removed the in-code comment in fillDataFormat.
2. The test helper now uses WorkbookFactory.create(File) directly and returns the data-format String, so no Cell outlives the closed workbook and no caller-supplied stream is leaked.
3. The test imports ExcelFormat instead of using the FQCN.

EmptyDateTimeFormatWriteTest 3/3 green, spotless clean.

[Sean-Walker0]

Follow-up: the branch was updated via the merge from main in the meantime, so the three review fixes are pushed as a normal commit on top of it: 0503c49 (EmptyDateTimeFormatWriteTest 3/3 green, spotless clean).