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