fix: ISO8601 should take priority over yyyyMMddHHmmss in Instant write, for issue #4003#7632
fix: ISO8601 should take priority over yyyyMMddHHmmss in Instant write, for issue #4003#7632wenshao wants to merge 1 commit into
Conversation
…e, for issue #4003 When the JSONWriter.Context has dateFormat="iso8601" (the runtime form that fastjson1's SerializerFeature.UseISO8601DateFormat resolves into) ISO8601 must take priority over any string-pattern shape flags such as yyyyMMddhhmmss19/14/8/10. Previously the codec evaluated those flags purely against the codec instance + context's pattern flags, so a configuration that had been set up with dateFormat="yyyy-MM-dd HH:mm:ss" and later switched to ISO8601 could still hit the yyyyMMddhhmmss19 path and produce "2026-02-24 14:50:00" instead of "2026-02-24T14:50:00Z". Compute a single iso8601 effective flag and gate the yyyyMMddhhmmss shape paths on !iso8601, so an explicit ISO8601 request always wins.
|
wenshao seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
wenshao
left a comment
wenshao
left a comment
There was a problem hiding this comment.
Automated review via /qreview. 1 suggestion inline. Submitted as a Comment (not Approve / Request changes) because this is a self-authored PR and CI is still running.
| } | ||
|
|
||
| @Test | ||
| public void testIso8601OverridesDefaultDateFormat() { |
There was a problem hiding this comment.
[Suggestion] None of the four tests in this class fail without the production change — I ran Issue4003 against the base main version of ObjectWriterImplInstant.java and got Tests run: 4, Failures: 0, Errors: 0. The suite passes with or without the fix, so it does not actually guard the issue-4003 regression.
Root cause: Context.setDateFormat("iso8601") recomputes all shape flags in one shot — it sets dateFormatISO8601 = true and formatyyyyMMddhhmmss19 = false in the same call, and both flags are only ever assigned inside setDateFormat, so they are mutually exclusive. After ctx.setDateFormat("iso8601") the context is equivalent to new Context("iso8601"), and the old code already took the ISO8601 branch because yyyyMMddhhmmss19 was already false. The conflicting state this patch guards against (iso8601 true and a yyyyMMdd* flag true) is not reachable through setDateFormat.
To make this a real regression test it needs to reproduce the actual trigger and fail on main without this change. If the real-world report originates from SerializerFeature.UseISO8601DateFormat / a feature bit rather than setDateFormat("iso8601"), note that the iso8601 variable here only consults formatISO8601 and context.isDateFormatISO8601() — it never inspects a feature flag — so this patch may not cover that path either. Worth confirming how 4003 reproduces before relying on this fix.
— automated review via /qreview
2 participants
Summary
JSONWriter.ContexthasdateFormat="iso8601"(the runtime form that fastjson1'sSerializerFeature.UseISO8601DateFormatresolves into) ISO8601 must take priority over any string-pattern shape flags such asyyyyMMddhhmmss19/14/8/10.dateFormat="yyyy-MM-dd HH:mm:ss"and later switched to ISO8601 could still hit theyyyyMMddhhmmss19path and produce"2026-02-24 14:50:00"instead of"2026-02-24T14:50:00Z".iso8601effective flag and gate theyyyyMMddhhmmssshape paths on!iso8601, so an explicit ISO8601 request always wins.Fixes #4003.
Test plan
Issue4003test covering: ISO8601 alone, ISO8601 after a defaultyyyy-MM-dd HH:mm:ss, defaultyyyy-MM-dd HH:mm:sswithout ISO8601 (regression), and no-format default.*Instant*,*ISO8601*,*DateTimeCodec*,Issue*tests pass (37 tests).