A DS2 timestamp or time column in a thread program loses precision


When a DS2 program specifies the variable type of TIMESTAMP on a new column in a thread program and that column is output in the data program, the precision of that column is not preserved. It instead falls back to the default precision for a TIMESTAMP.

To circumvent the problem, duplicate the declaration of the timestamp variable from the thread program in the data program. The sample code below illustrates this. This code assumes that you have established a connection to Hadoop with a LIBNAME statement, submitted the location of the configuration and JAR files, and have a data set stored there.

A thread program named T creates a TIMESTAMP column named Col2. The thread program is used in the data program. If the line of code with the asterisk is omitted, the loss of precision occurs. With that line of code, the precision is maintained.

proc ds2 indb=no;
   thread t/overwrite=yes;
   dcl timestamp(9) col2;
   method run(); 
      set yourHadoopDataSet;
      col2 = timestamp"2016-03-12 08:00:00.91";
   end;
   endthread; 
run;
quit;

proc ds2 indb=no;
   data dblib.bde_out (overwrite=yes);
      dcl timestamp(9) col2;
      dcl thread t t1;
      method run();
         set from t1;
/* This line of code must be added to prevent the precision problem */
      * col2 = timestamp"2016-03-12 08:00:00.91";
        put col2=;
      end;
   enddata; 
run;
quit;

The precision of a TIME or TIMESTAMP variable type is now the DS2-defined default, which is six digits after the decimal point, rather than using the default for a given database.