You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@orc.apache.org by "Owen O'Malley (JIRA)" <ji...@apache.org> on 2018/02/26 23:53:00 UTC

[jira] [Assigned] (ORC-306) Fix incorrect workaround for bug in java.sql.Timestamp

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

Owen O'Malley reassigned ORC-306:
---------------------------------


> Fix incorrect workaround for bug in java.sql.Timestamp
> ------------------------------------------------------
>
>                 Key: ORC-306
>                 URL: https://issues.apache.org/jira/browse/ORC-306
>             Project: ORC
>          Issue Type: Test
>            Reporter: Owen O'Malley
>            Assignee: Owen O'Malley
>            Priority: Major
>
> There is a bug in java.sql.Timestamp where if the timestamp is of the form "YYYY-MM-DD HH:MM:SS.000XXX" and year is before 1970, the resulting time is off by one second. Unfortunately, the ORC reader was unintentionally triggering this case for all timestamps before 1970 and thus included compensating code to correct the problem.
> Unfortunately, the workaround means that the user get incorrect results if they don't use Timestamp to interpret the results.*1900-05-05 12:34:56.1* is stored in TimestampColumnVector as -2198201103900 millis and 100000000 nanos. The ORC reader incorrectly restores that as -2198201103000 and 100000000 (notice the missing 900 millis), then adjusts the millis to -2198201102000. Since the last three digits of the millis are 0 that triggers the Timestamp bug and becomes the matching *1900-05-05 12:34:56.1*. 
> So basically, ORC added a bug to compensate for Java's bug.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)