Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7169A1032A for ; Thu, 7 May 2015 05:26:05 +0000 (UTC) Received: (qmail 39627 invoked by uid 500); 7 May 2015 05:26:00 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 39547 invoked by uid 500); 7 May 2015 05:26:00 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 39536 invoked by uid 99); 7 May 2015 05:26:00 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2015 05:26:00 +0000 Date: Thu, 7 May 2015 05:26:00 +0000 (UTC) From: "Henry Kang (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (LANG-1121) FastDateFormat.parse() does not handle wrong length string MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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)