streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbnks <>
Subject [GitHub] incubator-streams pull request: Added DateFormatters to the RF3339...
Date Mon, 28 Apr 2014 14:54:19 GMT
Github user rbnks commented on a diff in the pull request:
    --- Diff: streams-pojo/src/main/java/org/apache/streams/data/util/ ---
    @@ -54,6 +56,68 @@ public static RFC3339Utils getInstance(){
         public static final DateTimeFormatter LOCAL_STANDARD_FMT = DateTimeFormat.forPattern(BASE_FMT
+ "Z").withZoneUTC();
         public static final DateTimeFormatter LOCAL_SUB_SECOND_FMT = DateTimeFormat.forPattern(BASE_FMT
+ ".SSSZ").withZoneUTC();
    +    /**
    +     * Contains various formats.  All formats should be of international standards when
comes to the ordering of the
    +     * days and month.
    +     */
    +    private static final  DateTimeFormatter DEFAULT_FORMATTER;
    +    /**
    +     * Contains alternative formats that will succeed after failures from the DEFAULT_FORMATTER.
    +     * i.e. 4/24/2014 will throw an exception on the default formatter because it will
assume international date standards
    +     * However, the date will parse in the ALT_FORMATTER because it contains the US format
of MM/dd/yyyy.
    +     */
    +    private static final DateTimeFormatter ALT_FORMATTER;
    +    static {
    +        DateTimeParser[] parsers = new DateTimeParser[]{
    +                DateTimeFormat.forPattern("EEE MMM dd HH:mm:ss Z yyyy").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd MMMM yyyy HH:mm:ss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyyMMdd").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd-MM-yyyy").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyy-MM-dd").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyy/MM/dd").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd MMM yyyy").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd MMMM yyyy").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyyMMddHHmm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyyMMdd HHmm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd-MM-yyyy HH:mm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyy-MM-dd HH:mm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyy/MM/dd HH:mm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd MMM yyyy HH:mm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd MMMM yyyy HH:mm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyyMMddHHmmss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyyMMdd HHmmss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd-MM-yyyy HH:mm:ss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("yyyy/MM/dd HH:mm:ss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd MMM yyyy HH:mm:ss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("HH:mm:ss yyyy/MM/dd").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("HH:mm:ss MM/dd/yyyy").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("HH:mm:ss yyyy-MM-dd").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("HH:mm:ss MM-dd-yyyy").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd/MM/yyyy HH:mm:ss").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd/MM/yyyy HH:mm").withZoneUTC().getParser(),
    +                DateTimeFormat.forPattern("dd/MM/yyyy").withZoneUTC().getParser(),
    +                UTC_STANDARD_FMT.getParser(),
    +                UTC_SUB_SECOND_FMT.getParser(),
    +                LOCAL_STANDARD_FMT.getParser(),
    +                LOCAL_SUB_SECOND_FMT.getParser()
    +        };
    +        DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
    +        builder.append(null, parsers);
    +        DEFAULT_FORMATTER = builder.toFormatter().withZoneUTC();
    +        DateTimeParser[] altParsers = new DateTimeParser[] {
    --- End diff --
    The ALT parses is not added to the default formatter because the alternate formats will
never get called.  The formatter only moves to the next when it fails to parse the String.
    Ex. if we have two parsers in the following order, in or formatter
    parser 1 format "dd/MM/yyyy"
    parser 2 format "MM/dd/yyyy"
    And we try to format the String "04/24/2014" the following will happen.
    Parser1 will be able to parse the format, but it will throw an InvalidArgumentException
when it tries to assign 24 as a month of the year.  This exception causes the formatter to
not try to parse with the second parser.
    So to get around situations like this, have put a default parser which should always have
international formats for the dates (the day before the months, etc) and an alternative formatter
that contains US date formats regarding months and day order.  If the international version
throws an exception, then the Alternative formatter is used.
    I tried to make the comments reflect this, obviously I did not make this clear enough.
 Any direction on what should be added to the comments to make this clear would be helpful.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message