Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
1 reply Latest Post - ‏2013-02-21T20:09:38Z by dstageevo
SystemAdmin
SystemAdmin
7754 Posts
ACCEPTED ANSWER

Pinned topic DS Java transformer - timestamp precision lost when writing to output row

‏2013-02-15T10:41:48Z |
Hi all, i use java transformer to perform timezone conversion on timestamp fields. It was OK until the requirement come to keep timestamp microseconds by timezone conversion. The java code is bulky, but the workflow is:
-read input row
-iterate columns
-if column is of timestamp type - read input value using getValueAsSQLTyped method
  • save microseconds value
  • call custom method to convert Timezone (using Date and Calendar)
  • add microseconds back
  • write output value using setValueAsSQLTyped method.

After some tests it appears that when reading input value with getValueAsSQLTyped - microseconds are kept. BUT - when writing output value with setValueAsSQLTyped -microseconds are lost.
Here is debugging output to illustrate the issue:

APT_CombinedOperatorController,1: sqlTypeName---> Timestamp
colName---> DATE1
in Tmst--> 2009-12-31 03:14:07.777215
date inside convertTmstTZ method--> 2009-12-31 03:14:07.777215
date after convertTZ --> Thu Dec 31 08:14:07 GMT 2009
Tmst after convertTZ --> 2009-12-31 08:14:07.0
Tmst after setNanos --> 2009-12-31 08:14:07.777215
outTmst---> 22009-12-31 08:14:07.777215
writing out Tmst value to TZA_---> 2009-12-31 08:14:07.777215-to column # 1
reading Tmst value back from output row---> 2009-12-31 08:14:07.0-from column # 1

Is it a bug in DS tr4j.jar? How to overcome it? Any thought would be appreciated!
Updated on 2013-02-21T20:09:38Z at 2013-02-21T20:09:38Z by dstageevo
  • dstageevo
    dstageevo
    16 Posts
    ACCEPTED ANSWER

    Re: DS Java transformer - timestamp precision lost when writing to output row

    ‏2013-02-21T20:09:38Z  in response to SystemAdmin
    Is it possible for you to return it via setValueAsString instead? Just a guess, but hopefully SetValueAsString() won't touch it and it will leave it "as is".

    Ernie