[
https://issues.apache.org/jira/browse/SQOOP-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235701#comment-14235701
]
Jarek Jarcec Cecho commented on SQOOP-1846:
-------------------------------------------
I see your comment [~vybs] - with current implementation it's more about
whether we want to fix it and how. I'm trying to go beyond that though - I know
that we're currently using JODA as the parsing library, but that don't have to
be the case for all connectors (IDFs) and all for all eternity, right? Hence I
would like to more answer question what we want to have in the CSV-ish IDF spec
and make the implementation according to that rather then the other way around.
If we feel that using ISO8601 is better regardless of the parsing library, I'm
all for to use that :)
To me the comparison between those two is as follows:
For ISO-8601:
* It's a standard, so any future parsing library should understand it
For "without T":
* It's something that other utilities seems to be following ({{mysqldump}},
{{pg_dump}}, ...)
I'm wondering what are other people thoughts?
> Does DateTime have be iso8601 compliant ? JODA requires it to be
> ----------------------------------------------------------------
>
> Key: SQOOP-1846
> URL: https://issues.apache.org/jira/browse/SQOOP-1846
> Project: Sqoop
> Issue Type: Sub-task
> Components: sqoop2-framework
> Reporter: Veena Basavaraj
> Fix For: 1.99.5
>
> Attachments: SQOOP-1846.patch
>
>
> I saw this test case I partially was responsible for and it does not make any
> sense to me anymore...
> {code}
> @Test
> public void testDateTimePrecisionWithCSVTextInObjectArrayOut() {
> Schema schema = new Schema("test");
> schema.addColumn(new DateTime("1"));
> dataFormat.setSchema(schema);
> dataFormat.setTextData("'2014-10-01 12:00:00.000'");
> assertEquals("2014-10-01T12:00:00.000-07:00",
> dataFormat.getObjectData()[0].toString());
> }
> {code}
> the spec in
> https://cwiki.apache.org/confluence/display/SQOOP/Sqoop2+CSV+Intermediate+representation
> does not mention / say that the date time has to be in iso8601 format. but
> with us using JODA for parsing datetime objects, it becomes imminent that the
> text representation of date-time has to have iso8601 format, see details here
> https://github.com/JodaOrg/joda-time/issues/11
> FIrst, are we ok with this?
> If so, then the following code replacing space to T in CSVIDF should be
> removed.
> {code}
> case DATE_TIME:
> // A datetime string with a space as date-time separator will not be
> // parsed expectedly. The expected separator is "T". See also:
> // https://github.com/JodaOrg/joda-time/issues/11
> String dateTime = removeQuotes(fieldString).replace(" ", "T");
>
> {code}
> then the test case will be like this, that makes sense now, because the FROM
> connector will set data in iso8601 format and it can expect it to be returned
> bacl in the dateTime format with the timezone that sqoop is prescribing it
> will support.
> {code}
> @Test
> public void testDateTimePrecisionWithCSVTextInObjectArrayOut() {
> Schema schema = new Schema("test");
> schema.addColumn(new DateTime("1"));
> dataFormat.setSchema(schema);
> dataFormat.setTextData("'2014-10-01T12:00:00.000'");
> assertEquals("2014-10-01T12:00:00.000-07:00",
> dataFormat.getObjectData()[0].toString());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
