Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Environment:
Talend Enterprise Big Data (5.4.1.r111943)
jdk 1.6.0_45
Windows 7
Problem description:
I'm using the tConvertType component to parse a string from a source database into a Date object. Depending on what data format string I use, the value of the date is changed.
I recreated this issue in a simple job to show the problem in isolation. I've attached the job here as example.zip and screenshots highlighting the important areas as example_screenshots.png.
example.zip_20150908-1933.zip
As shown in example.zip, the input is the string "2014-10-09T14:58:34359699Z" but the output is "2015-11-11T07:19:39" when the format string "yyyy-MM-dd'T'HH:mm:ss" is used.
The field date_2 holds a second copy of the same input string and shows that it is preserved when the format string "yyyy-MM-dd HH:mm:ss" is used.
Secondary issue:
When the format string "yyyy-MM-dd HH:mm:ss" is used (attempting to work around the problem), strings not matching the format string throw a NumberFormatException. For example, for the string "string", Talend attempts to parse the first 4 characters "stri" as the year. The result is the message below (table from a tLogRow attached to the tConvertType rejects output). This seems inconsistent with the behaviour I've seen before where the row would be sent to rejects without raising an unhandled exception.
Talend Enterprise Big Data (5.4.1.r111943)
jdk 1.6.0_45
Windows 7
Problem description:
I'm using the tConvertType component to parse a string from a source database into a Date object. Depending on what data format string I use, the value of the date is changed.
I recreated this issue in a simple job to show the problem in isolation. I've attached the job here as example.zip and screenshots highlighting the important areas as example_screenshots.png.
example.zip_20150908-1933.zip
As shown in example.zip, the input is the string "2014-10-09T14:58:34359699Z" but the output is "2015-11-11T07:19:39" when the format string "yyyy-MM-dd'T'HH:mm:ss" is used.
The field date_2 holds a second copy of the same input string and shows that it is preserved when the format string "yyyy-MM-dd HH:mm:ss" is used.
Secondary issue:
When the format string "yyyy-MM-dd HH:mm:ss" is used (attempting to work around the problem), strings not matching the format string throw a NumberFormatException. For example, for the string "string", Talend attempts to parse the first 4 characters "stri" as the year. The result is the message below (table from a tLogRow attached to the tConvertType rejects output). This seems inconsistent with the behaviour I've seen before where the row would be sent to rejects without raising an unhandled exception.
java.lang.NumberFormatException: For input string: "stri"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:449)
at java.lang.Integer.parseInt(Integer.java:499)
at routines.system.FastDateParser$DateTimeParser.parse(FastDateParser.java:206)
at java.text.DateFormat.parse(DateFormat.java:335)
at routines.TalendDate.parseDate(TalendDate.java:809)
at routines.system.TypeConvert.String2Date(TypeConvert.java:4117)
at pdwserver.test_brokendateformat_0_1.test_brokenDateFormat.tFixedFlowInput_1Process(test_brokenDateFormat.java:1190)
at pdwserver.test_brokendateformat_0_1.test_brokenDateFormat.runJobInTOS(test_brokenDateFormat.java:1724)
at pdwserver.test_brokendateformat_0_1.test_brokenDateFormat.main(test_brokenDateFormat.java:1589)
.--------------------------------------------------------------------------------------.
| #1. tLogRow_2 |
+--------------+-----------------------------------------------------------------------+
| key | value |
+--------------+-----------------------------------------------------------------------+
| date | 2015-11-11T07:19:39 |
| date_2 | null |
| errorCode | 2 |
| errorMessage | date_2:java.text.ParseException: Unparseable date: "string" - Line: 0 |
+--------------+-----------------------------------------------------------------------+