Fix timezone parsing regression in FastDateParser

[ujwal2203]

Summary

Fixes timezone parsing regression in FastDateParser that broke backward compatibility in commons-lang 3.5+.

Problem

DateUtils.parseDate with pattern "yyyy-MM-dd'T'HH:mm:ss.SSSZZ" fails to parse timezone offsets without colon (e.g., -0500) in versions 3.5+. This worked in version 3.4.

Example failing code:
// This throws ParseException in 3.5+ but worked in 3.4
DateUtils.parseDate("2019-06-11T15:06:11.716-0500", "yyyy-MM-dd'T'HH:mm:ss.SSSZZ");

Root Cause

The regex pattern for ISO_8601_3_STRATEGY in FastDateParser.java requires a colon between hours and minutes: (?::).

The current regex at line 923:
private static final Strategy ISO_8601_3_STRATEGY = new ISO8601TimeZoneStrategy("(Z|(?:[+-]\d{2}(?::)\d{2}))");

Solution

Changed the regex to make colon optional: (?::?). This allows both formats:

• -05:00 (with colon, ISO 8601 style)
• -0500 (without colon, RFC 822 style)

Updated regex:
private static final Strategy ISO_8601_3_STRATEGY = new ISO8601TimeZoneStrategy("(Z|(?:[+-]\d{2}(?::?)\d{2}))");

Changes Made

1. Modified FastDateParser.java line 923: changed (?::) to (?::?)

Testing Considerations

• The fix maintains backward compatibility with 3.4 behavior
• Both formats (with and without colon) should now parse correctly
• Existing tests for timezone parsing should continue to pass

References

• Fixes issue LANG-1805: https://issues.apache.org/jira/browse/LANG-1805
• Original bug report from 2019 with exact test case
• Related to previous attempt in PR 436

Checklist

• Code follows the project's existing style
• Change is minimal and focused on the issue
• No new warnings introduced
• Documentation not needed (internal regex change)

Fixes: LANG-1805

[garydgregory]

Hello @ujwal2203

Thank you for your PR.

-1 as the PR stands: Your PR is missing a unit test to show your change to main actually fixes something. The new test should fail if the change to the main side of the tree is not applied.

Gary

[garydgregory]

Ping @ujwal2203

Your PR is missing a unit test to show your change to main actually fixes something. See my previous comment #1543 (review)

[ujwal2203]

Summary

Adjusted ISO-8601 timezone parsing to preserve backward-compatible behavior while clarifying supported formats. The change ensures that both colon-separated and non-colon timezone offsets continue to be accepted, consistent with historical behavior in Commons Lang.

Testing

Added a JUnit test method in FastDateParserTest to explicitly cover supported ISO-8601 timezone formats:

• Z
• ±HH
• ±HHMM
• ±HH:MM
• Verified that all existing timezone parsing tests continue to pass.

Compatibility

• Maintains backward compatibility with Commons Lang 3.4 behavior.
• No change to accepted input formats; parsing behavior remains consistent.

Checklist

• Code follows existing project style
• Change is minimal and focused
• No new warnings introduced
• Tests added to cover supported behaviour

[ujwal2203]

did changes in test method

[garydgregory]

Hello @ujwal2203

Thank you for your update. Please rebase this PR on git master.

[garydgregory]

Hello @ujwal2203

There are no regressions based on the current state of this PR, which no longer matches its title.

I added FastDateParserTest.testISO8601TimeZoneVariants() to git master which is similar to the new test in the PR with the addition of assertions. Unless there is a bug to fix or missing code coverage, I think you can close the PR.

Thank you.

[ujwal2203]

Yeah it was a new experience and its my first time thanks for you kindness and patience @garydgregory closing the PR