Github user rbnks commented on a diff in the pull request:
https://github.com/apache/incubator-streams/pull/4#discussion_r12049758
--- Diff:
streams-pojo/src/main/java/org/apache/streams/data/util/RFC3339Utils.java ---
@@ -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 [email protected] or file a JIRA ticket
with INFRA.
---
