Bug #107389 for DateTime-Format-CLDR: Long year captures short year by mistake

Mon Sep 28 11:07:21 2015 bbkr [...] post.pl - Ticket created

Subject:

Long year captures short year by mistake

https://github.com/maros/DateTime-Format-CLDR/blob/master/lib/DateTime/Format/CLDR.pm#L28 Because short year \d{2} is not excluded from range the parser incorrectly matches 04-01-15 to pattern yyyy-MM-dd and returns it as year 0004 instead of fail. Module should follow rules in: http://search.cpan.org/~drolsky/DateTime-1.20/lib/DateTime.pm#CLDR_Patterns y and y{3,} - long form yy - special case of short form u{1,} - same as y but without short form exception

Fri Dec 25 04:24:01 2015 MAROS [...] cpan.org - Correspondence added

This issue has been fixed in 1.17 (Fri Oct 16 2015)

Fri Dec 25 04:24:01 2015 The RT System itself - Status changed from 'new' to 'open'

Fri Dec 25 04:24:02 2015 MAROS [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Dec 25 04:24:08 2015 MAROS [...] cpan.org - Fixed in 1.17 added

Mon Apr 25 11:31:48 2016 bbkr [...] post.pl - Status changed from 'resolved' to 'open'

Mon Apr 25 11:35:44 2016 bbkr [...] post.pl - Correspondence added

From:

bbkr [...] post.pl

Hi The bug is still there. year_long => qr/(-?\d{1,4})/o, year_short => qr/(-?\d{2})/o, Those two regexps MUST be mutually exclusive. While now both will capture "04". Correct regexp for year_long should be \d|\d{3,} (exactly one digit or three or more digits, two digits MUST NOT match).