fix: support negative year (BC date) deserialization

[daguimu]

Problem

LocalDateTime with negative years (BC dates) serializes correctly (e.g. "-0001-12-31 16:00:00") but fails to deserialize with:

JSONException: read LocalDateTime error -0001-12-31 16:00:00

Reproduction:

LocalDateTime time = LocalDateTime.of(0, 1, 1, 0, 0, 0, 0).minusHours(8);
JSONObject bean = new JSONObject().fluentPut("time", time);
String s = bean.toJSONString();  // {"time":"-0001-12-31 16:00:00"}
JSON.parseObject(s).getLocalDateTime("time");  // throws JSONException

Root Cause

The negative year date string "-0001-12-31 16:00:00" has length 20 (due to the leading -). The readLocalDateTime() method dispatches length-20 strings to parseLocalDateTime20(), which expects a completely different format (dd Mon yyyy HH:mm:ss). This returns null, and the string eventually falls through to an error.

Fix

Added handling for the -yyyy-MM-dd HH:mm:ss format in the string fallback path of readLocalDateTime(). The fix:

• Checks if the string is 20 chars starting with -
• Validates the format matches -yyyy-MM-dd HH:mm:ss (supporting both and T separators, and / delimiters)
• Manually parses the year, month, day, hour, minute, second components
• Follows the same manual parsing style used throughout the codebase

Tests Added

• testNegativeYearRoundTrip — Serialize then deserialize a BC date, verify equality
• testNegativeYearDirectParse — Parse "-0001-12-31 16:00:00" and verify all components
• testNegativeYearWithT — Parse with T separator: "-0001-12-31T16:00:00"
• testNegativeYearWithSlash — Parse with / delimiter: "-0001/12/31 16:00:00"
• testNegativeYearLarger — Year -100 (101 BC) round-trip
• testPositiveYearStillWorks — Regression test for normal dates

Impact

Minimal — only affects deserialization of negative year datetime strings (20 chars starting with -). Normal date parsing is unaffected.

Fixes #3845

[wenshao]

[Critical] The new negative-year parser computes numeric fields with str.charAt(i) - '0' but does not validate that those positions are actually digits, and the time fields only have upper-bound checks. Inputs with valid separators but non-digit numeric characters can be coerced into different valid values instead of being rejected; for example, -0001-12-3/ 16:00:00 can parse the day as 29 because '/' - '0' == -1. Please validate every numeric position before computing the fields, or use existing digit helpers that reject non-digits, and require lower bounds for hour/minute/second as well.

— gpt-5.5 via Qwen Code /review