[jira] [Commented] (LANG-1121) FastDateFormat.parse() does not handle wrong length string

["Henry Kang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LANG-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14532030#comment-14532030 ] 

Henry Kang commented on LANG-1121:
----------------------------------

Thanks for commit tests.
I agree that is same behavior as SimpleDateFormat.
However, It is incorrect operation, I think.

format : yyyyMMdd
input : 20150429113100

It matches pattern (\p{Nd{4}}+)(\p{Nd{2}+)(\p{Nd}++).
It works yyyy, MM, and the others are dd (don't care how long digits)

Is there any plan for patches, or not?

> FastDateFormat.parse() does not handle wrong length string
> ----------------------------------------------------------
>
>                 Key: LANG-1121
>                 URL: https://issues.apache.org/jira/browse/LANG-1121
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.time.*
>    Affects Versions: 3.3.2
>            Reporter: Henry Kang
>            Assignee: Charles Honton
>            Priority: Minor
>             Fix For: Patch Needed
>
>
> FDFP does not handled wrong length string.
> for example,
> {code}
> // Wed Apr 29 00:00:00 KST 2015
> FastDateFormat.getInstance("yyyyMMdd").parse("20150429");
> // throws ParseException
> FastDateFormat.getInstance("yyyyMMdd").parse("2015");
> // Thu Mar 16 00:00:00 KST 81724
> FastDateFormat.getInstance("yyyyMMdd").parse("20150429113100");
> {code}
> I think result of third throws ParseException,
> but FastDateFormat.parse() returns wrong year, ex, 81724 instead of 2015.
> As I tested,
> regex.matcher.group => (2015)(04)(29113100) => setCalendar => March 16, 81724



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)