You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Michael Osipov (JIRA)" <ji...@apache.org> on 2019/03/18 13:33:00 UTC

[jira] [Comment Edited] (LANG-1439) FastDateParser throws NumberFormatException when parsing a long number based on a ISO8601 string

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

Michael Osipov edited comment on LANG-1439 at 3/18/19 1:32 PM:
---------------------------------------------------------------

The given format is not ISO 8601 compliant. {{999999999999}} is larger than {{Integer.MAX_VALUE}}. I just checked the standard, chapter 3.5 says that "Year" must be a four-digit value. By mutual agreement between parties it can be negative or > 9999. So the parse is broken here. Simply wrapping the exception is wrong.


was (Author: michael-o):
The given format is not ISO 8601 compliant.

> FastDateParser throws NumberFormatException when parsing a long number based on a ISO8601 string
> ------------------------------------------------------------------------------------------------
>
>                 Key: LANG-1439
>                 URL: https://issues.apache.org/jira/browse/LANG-1439
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.time.*
>    Affects Versions: 3.8.1
>            Reporter: Nghia Nguyen
>            Priority: Major
>         Attachments: suggested-fix.patch
>
>
> Given this piece of code:
> {code:java}
>     @Test
>     public void testParseLongNumber() {
>         final DateParser fdf = getInstance("yyyy-MM-dd'T'HH:mm:ssZZ");
>         fdf.parse("999999999999"); // NFE here
>     }
> {code}
> Internally, the *FastDateParser.NumberStrategy::parse* method parses the year from that number (without maxWidth because the next part is not a number) using *Integer::parseInt* thus leading to a NumberFormatException.
> A quick fix for this would be catching the NFE then return false after setting the error position so that the FastDateParse::Parse method can throw a ParseException correctly.
> Edit: the suggested patch is attached below



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)