Working with Dates

The Integration Service and database can process dates differently. When you
configure the session to push date conversion to the database, you can receive
unexpected results or the session can fail.
The database can produce different output than the Integration Service when the
following date settings and conversions are different:
Date values converted to character values. The Integration Service converts
the transformation Date/Time datatype to the native datatype that supports
subsecond precision in the database. The session fails if you configure the
datetime format in the session to a format that the database does not support. For
example, when the Integration Service performs the ROUND function on a date, it
stores the date value in a character column, using the format MM/DD/YYYY
HH:MI:SS.US. When the database performs this function, it stores the date in the
default date format for the database. If the database is Oracle, it stores the date
as the default DD-MON-YY. If you require the date to be in the format MM/DD/YYYY
HH:MI:SS.US, you can disable pushdown optimization.
Date formats for TO_CHAR and TO_DATE functions. The Integration Service uses
the date format in the TO_CHAR or TO_DATE function when the Integration Service
pushes the function to the database. The database converts each date string to a
datetime value supported by the database.
For example, the Integration Service pushes the following expression to the
database:
TO_DATE( DATE_PROMISED, 'MM/DD/YY' )
The database interprets the date string in the DATE_PROMISED port based on the
specified date format string MM/DD/YY. The database converts each date string, such
as 01/22/98, to the supported date value, such as Jan 22 1998 00:00:00.
If the Integration Service pushes a date format to an IBM DB2, a Microsoft SQL
Server, or a Sybase database that the database does not support, the Integration
Service stops pushdown optimization and processes the transformation.
The Integration Service converts all dates before pushing transformations to an
Oracle or Teradata database. If the database does not support the date format after
the date conversion, the session fails.
HH24 date format. You cannot use the HH24 format in the date format string
for Teradata. When the Integration Service generates SQL for a Teradata database,
it uses the HH format string instead.
Blank spaces in date format strings. You cannot use blank spaces in the date
format string in Teradata. When the Integration Service generates SQL for a
Teradata database, it substitutes the space with ‘B.’
Handling subsecond precision for a Lookup transformation. If you enable
subsecond precision for a Lookup transformation, the database and Integration
Service perform the lookup comparison using the subsecond precision, but return
different results. Unlike the Integration Service, the database does not truncate
the lookup results based on subsecond precision. For example, you configure the
Lookup transformation to show subsecond precision to the millisecond. If the lookup
result is 8:20:35.123456, a database returns 8:20:35.123456, but the Integration
Service returns 8:20:35.123.
SYSDATE built-in variable. When you use the SYSDATE built-in variable, the
Integration Service returns the current date and time for the node running the
service process. However, when you push the transformation logic to the database,
the SYSDATE variable returns the current date and time for the machine hosting the
database. If the time zone of the machine hosting the database is not the same as
the time zone of the machine running the Integration Service process, the results
can vary.

Working with Dates

The Integration Service and database can process dates differently. When you
configure the session to push date conversion to the database, you can receive
unexpected results or the session can fail.
The database can produce different output than the Integration Service when the
following date settings and conversions are different:
Date values converted to character values. The Integration Service converts
the transformation Date/Time datatype to the native datatype that supports
subsecond precision in the database. The session fails if you configure the
datetime format in the session to a format that the database does not support. For
example, when the Integration Service performs the ROUND function on a date, it
stores the date value in a character column, using the format MM/DD/YYYY
HH:MI:SS.US. When the database performs this function, it stores the date in the
default date format for the database. If the database is Oracle, it stores the date
as the default DD-MON-YY. If you require the date to be in the format MM/DD/YYYY
HH:MI:SS.US, you can disable pushdown optimization.
Date formats for TO_CHAR and TO_DATE functions. The Integration Service uses
the date format in the TO_CHAR or TO_DATE function when the Integration Service
pushes the function to the database. The database converts each date string to a
datetime value supported by the database.
For example, the Integration Service pushes the following expression to the
database:
TO_DATE( DATE_PROMISED, 'MM/DD/YY' )
The database interprets the date string in the DATE_PROMISED port based on the
specified date format string MM/DD/YY. The database converts each date string, such
as 01/22/98, to the supported date value, such as Jan 22 1998 00:00:00.
If the Integration Service pushes a date format to an IBM DB2, a Microsoft SQL
Server, or a Sybase database that the database does not support, the Integration
Service stops pushdown optimization and processes the transformation.
The Integration Service converts all dates before pushing transformations to an
Oracle or Teradata database. If the database does not support the date format after
the date conversion, the session fails.
HH24 date format. You cannot use the HH24 format in the date format string
for Teradata. When the Integration Service generates SQL for a Teradata database,
it uses the HH format string instead.
Blank spaces in date format strings. You cannot use blank spaces in the date
format string in Teradata. When the Integration Service generates SQL for a
Teradata database, it substitutes the space with ‘B.’
Handling subsecond precision for a Lookup transformation. If you enable
subsecond precision for a Lookup transformation, the database and Integration
Service perform the lookup comparison using the subsecond precision, but return
different results. Unlike the Integration Service, the database does not truncate
the lookup results based on subsecond precision. For example, you configure the
Lookup transformation to show subsecond precision to the millisecond. If the lookup
result is 8:20:35.123456, a database returns 8:20:35.123456, but the Integration
Service returns 8:20:35.123.
SYSDATE built-in variable. When you use the SYSDATE built-in variable, the
Integration Service returns the current date and time for the node running the
service process. However, when you push the transformation logic to the database,
the SYSDATE variable returns the current date and time for the machine hosting the
database. If the time zone of the machine hosting the database is not the same as
the time zone of the machine running the Integration Service process, the results
can vary.

Working with Dates

The Integration Service and database can process dates differently. When you
configure the session to push date conversion to the database, you can receive
unexpected results or the session can fail.
The database can produce different output than the Integration Service when the
following date settings and conversions are different:
Date values converted to character values. The Integration Service converts
the transformation Date/Time datatype to the native datatype that supports
subsecond precision in the database. The session fails if you configure the
datetime format in the session to a format that the database does not support. For
example, when the Integration Service performs the ROUND function on a date, it
stores the date value in a character column, using the format MM/DD/YYYY
HH:MI:SS.US. When the database performs this function, it stores the date in the
default date format for the database. If the database is Oracle, it stores the date
as the default DD-MON-YY. If you require the date to be in the format MM/DD/YYYY
HH:MI:SS.US, you can disable pushdown optimization.
Date formats for TO_CHAR and TO_DATE functions. The Integration Service uses
the date format in the TO_CHAR or TO_DATE function when the Integration Service
pushes the function to the database. The database converts each date string to a
datetime value supported by the database.
For example, the Integration Service pushes the following expression to the
database:
TO_DATE( DATE_PROMISED, 'MM/DD/YY' )
The database interprets the date string in the DATE_PROMISED port based on the
specified date format string MM/DD/YY. The database converts each date string, such
as 01/22/98, to the supported date value, such as Jan 22 1998 00:00:00.
If the Integration Service pushes a date format to an IBM DB2, a Microsoft SQL
Server, or a Sybase database that the database does not support, the Integration
Service stops pushdown optimization and processes the transformation.
The Integration Service converts all dates before pushing transformations to an
Oracle or Teradata database. If the database does not support the date format after
the date conversion, the session fails.
HH24 date format. You cannot use the HH24 format in the date format string
for Teradata. When the Integration Service generates SQL for a Teradata database,
it uses the HH format string instead.
Blank spaces in date format strings. You cannot use blank spaces in the date
format string in Teradata. When the Integration Service generates SQL for a
Teradata database, it substitutes the space with ‘B.’
Handling subsecond precision for a Lookup transformation. If you enable
subsecond precision for a Lookup transformation, the database and Integration
Service perform the lookup comparison using the subsecond precision, but return
different results. Unlike the Integration Service, the database does not truncate
the lookup results based on subsecond precision. For example, you configure the
Lookup transformation to show subsecond precision to the millisecond. If the lookup
result is 8:20:35.123456, a database returns 8:20:35.123456, but the Integration
Service returns 8:20:35.123.
SYSDATE built-in variable. When you use the SYSDATE built-in variable, the
Integration Service returns the current date and time for the node running the
service process. However, when you push the transformation logic to the database,
the SYSDATE variable returns the current date and time for the machine hosting the
database. If the time zone of the machine hosting the database is not the same as
the time zone of the machine running the Integration Service process, the results
can vary.

Working with Dates

The Integration Service and database can process dates differently. When you
configure the session to push date conversion to the database, you can receive
unexpected results or the session can fail.
The database can produce different output than the Integration Service when the
following date settings and conversions are different:
Date values converted to character values. The Integration Service converts
the transformation Date/Time datatype to the native datatype that supports
subsecond precision in the database. The session fails if you configure the
datetime format in the session to a format that the database does not support. For
example, when the Integration Service performs the ROUND function on a date, it
stores the date value in a character column, using the format MM/DD/YYYY
HH:MI:SS.US. When the database performs this function, it stores the date in the
default date format for the database. If the database is Oracle, it stores the date
as the default DD-MON-YY. If you require the date to be in the format MM/DD/YYYY
HH:MI:SS.US, you can disable pushdown optimization.
Date formats for TO_CHAR and TO_DATE functions. The Integration Service uses
the date format in the TO_CHAR or TO_DATE function when the Integration Service
pushes the function to the database. The database converts each date string to a
datetime value supported by the database.
For example, the Integration Service pushes the following expression to the
database:
TO_DATE( DATE_PROMISED, 'MM/DD/YY' )
The database interprets the date string in the DATE_PROMISED port based on the
specified date format string MM/DD/YY. The database converts each date string, such
as 01/22/98, to the supported date value, such as Jan 22 1998 00:00:00.
If the Integration Service pushes a date format to an IBM DB2, a Microsoft SQL
Server, or a Sybase database that the database does not support, the Integration
Service stops pushdown optimization and processes the transformation.
The Integration Service converts all dates before pushing transformations to an
Oracle or Teradata database. If the database does not support the date format after
the date conversion, the session fails.
HH24 date format. You cannot use the HH24 format in the date format string
for Teradata. When the Integration Service generates SQL for a Teradata database,
it uses the HH format string instead.
Blank spaces in date format strings. You cannot use blank spaces in the date
format string in Teradata. When the Integration Service generates SQL for a
Teradata database, it substitutes the space with ‘B.’
Handling subsecond precision for a Lookup transformation. If you enable
subsecond precision for a Lookup transformation, the database and Integration
Service perform the lookup comparison using the subsecond precision, but return
different results. Unlike the Integration Service, the database does not truncate
the lookup results based on subsecond precision. For example, you configure the
Lookup transformation to show subsecond precision to the millisecond. If the lookup
result is 8:20:35.123456, a database returns 8:20:35.123456, but the Integration
Service returns 8:20:35.123.
SYSDATE built-in variable. When you use the SYSDATE built-in variable, the
Integration Service returns the current date and time for the node running the
service process. However, when you push the transformation logic to the database,
the SYSDATE variable returns the current date and time for the machine hosting the
database. If the time zone of the machine hosting the database is not the same as
the time zone of the machine running the Integration Service process, the results
can vary.