pjfanning opened a new pull request, #1400:
URL: https://github.com/apache/poi/pull/1400
Fixes #1397.
All results below are for 45000.6 (2023-03-15 14:24), and are the same for
`Locale.CHINA` and `Locale.US`.
| Format | Before | After |
|---|---|---|
| `yyyy"年"m"月"d"日"` | `2023"年"3"月"15"日"` | `2023年3月15日` |
| `d"-"mmm` | `15"-"Mar` | `15-Mar` |
| `h"时"mm"分"ss"秒"`, `h时mm分ss秒` | `45000.6` | `14时24分00秒` |
| `yyyy"年"m"月"d"日" h"时"mm"分"` | `45000.6` | `2023年3月15日 14时24分` |
| `上午/下午h"时"mm"分"`, `yyyy/m/d 上午/下午h:mm` | `45000.6` | `下午2时24分`, `2023/3/15
下午2:24` |
| `[DBNum1]yyyy"年"m"月"d"日"` (also with `[$-804]` before or after) |
`IllegalArgumentException` | `2023年3月15日` |
| `[DBNum2]0.00` | `[DBNum2]45000.60` | `45000.60` |
## Changes
- **Quoted literals in date formats:** `"text"` is converted into
`SimpleDateFormat` quoting (`'text'`, with `'` escaped as `''`). Previously the
quote marks reached `SimpleDateFormat` and were displayed. A `"` with no
closing quote is left as it is, so the existing `testBug54786` cases still pass.
- **`DateUtil.isADateFormat`:**
- `date_ptrn3b` now also allows 时, 分, 秒 and Japanese 時, next to the 年月日 it
already allowed. This is tighter than Fesod's approach, which matches any
年月日时分秒 character: `0.00"m/秒"` is still not a date, and there's a test for that.
- `上午/下午` (Excel's Chinese AM/PM marker, which usually comes *before* the
time) is ignored when checking.
- `[DBNumN]` is also stripped when it comes after `[$-…]`.
- **`上午/下午` in `createDateFormat`:** it maps to Java's `a`, the hour becomes
12-hour, and the AM/PM strings are set to 上午/下午, so the Chinese marker is shown
whatever the locale.
- **Non-ASCII letters** in a date format, such as an unquoted 时, are literal
text. They no longer reset the "an `m` after `h` is minutes" logic. Before
this, `h时mm分` showed the month instead of the minutes. Only ASCII letters are
pattern letters for `SimpleDateFormat`, and quoted text already behaved this
way.
- **`[DBNum1]`–`[DBNum3]`** are stripped, the same way colour codes are.
Arabic digits are shown instead of the Chinese/Japanese numerals Excel shows.
- **Date-format fallback:** when a date format can't be parsed, the
number-format fallback is now given the number instead of a `Date`. Before this
it threw `IllegalArgumentException: Cannot format given Object as a Number`.
`testBug54786` asserted that exception, so it now asserts the number-format
result (`0.041666667`, the same as the other invalid format in that test).
## Verification
- Most of the test formats are the zh-CN built-in number formats from
ECMA-376 Part 1 §18.8.30 (e.g. ids 31–35: `yyyy"年"m"月"d"日"`, `h"时"mm"分"`,
`h"时"mm"分"ss"秒"`, `上午/下午h"时"mm"分"`, `上午/下午h"时"mm"分"ss"秒"`), so they are formats
Excel really writes.
- There is no Excel-computed output for these formats in `test-data`. The
expected text follows from the format codes, but two choices are approximations:
- `上午/下午` always shows Chinese, in any locale.
- `[DBNum]` shows Arabic digits rather than Excel's Chinese numerals.
- `TestDataFormatter`, `TestDateUtil`, `TestExcelStyleDateFormatter`,
`TestHSSFDataFormatter`, `TestHSSFDateUtil` and `TestXSSFDataFormat` pass
locally.
- I also ran the Excel-validated `TestDataFormatterAgainstExcel` from #1398
against this branch. All 569 cases pass, and none of the listed known failures
changed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
