[ 
https://issues.apache.org/jira/browse/SQOOP-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michele Giusto updated SQOOP-1420:
----------------------------------

    Summary: Wrong timestamp lower/upper bounds due to timezone  (was: Wrong 
timestamp upper bound due to timezone)

> Wrong timestamp lower/upper bounds due to timezone
> --------------------------------------------------
>
>                 Key: SQOOP-1420
>                 URL: https://issues.apache.org/jira/browse/SQOOP-1420
>             Project: Sqoop
>          Issue Type: Bug
>          Components: connectors/oracle
>    Affects Versions: 1.4.4
>            Reporter: Michele Giusto
>
> Hi,
> I am using Sqoop 1.4.4 to do incremental imports from an Oracle database, 
> checking a timestamp column representing the instant of last update. The 
> timestamp column is in GMT, while the server running Sqoop is in GMT+2, and I 
> am looking for updates every 15 minutes. Due to the different timezones, 
> Sqoop launches queries filtering on timestamp ranges that are in the future, 
> resulting in no rows exported.
> Looking at the source code of Sqoop, it seems that to calculate the upper 
> bound (lower bound at next iteration) for the query, the program gets the 
> current time in millisecond (getCurrentDbTimestamp() in 
> org.apache.sqoop.manager.ConnManager) and creates a java.sql.Timestamp object 
> from it. Then, org.apache.sqoop.tool.ImportTool calls 
> datetimeToQueryString(String datetime, int columnType) of 
> org.apache.sqoop.manager.OracleManager passing the timestamp as a string, and 
> get back the sql filter to put in the final query. The problem seems to be 
> that the toString() method of a java.sql.Timestamp object considers the 
> user.timezone of the JVM (Europe/Rome in my case), so I get a String 
> representing a date that is in the future if considered as GMT (as the Oracle 
> database does with the SQL function TO_TIMESTAMP).
> To solve this problem, it may be enough to force the conversion from 
> Timestamp to String to work in GMT timezone (like setting user.timezone=GMT). 
> Another solution, when interacting with Oracle, may be to use the 
> TO_TIMESTAMP_TZ function, that allows to specify the timezone of the String 
> representing the timestamp.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to