[
https://issues.apache.org/jira/browse/LANG-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14532030#comment-14532030
]
Henry Kang edited comment on LANG-1121 at 5/7/15 5:26 AM:
----------------------------------------------------------
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 below
{code}(\p{Nd{4}}+)(\p{Nd{2}+)(\p{Nd}++){code}
It works yyyy, MM, and the others are dd (don't care how long digits)
Is there any plan for patches, or not?
was (Author: freeism):
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)
