[ 
https://issues.apache.org/jira/browse/CALCITE-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788244#comment-16788244
 ] 

Andrei Sereda commented on CALCITE-2818:
----------------------------------------

[~julianhyde] While reviewing this PR I have noticed that {{extract}} function 
has different semantics depending on vendor. 

{code:sql}
extract(millisecond from TIMESTAMP '1969-12-31 21:13:17.357')
{code}

Will return {{357}} in Oracle and SQL Server but {{17357}} in Postgres. 

Do you think implementation should be different depending on current dialect  ? 
This is a separate discussion not related to current PR.  

> EXTRACT returns wrong results for DATE and TIMESTAMP values before epoch
> ------------------------------------------------------------------------
>
>                 Key: CALCITE-2818
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2818
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Mickaël Sauvée
>            Priority: Major
>              Labels: easyfix, pull-request-available
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Implementation of Extract (ExtractImplementor) returns wrong result for dates 
> before Epoch. 
> Computation is based on Java modulo that have a certain behavior on negative 
> number.
> For extracting hour, minutes and seconds, the computation is wrong.
> Here is an example on hour extract with the date 30-12-1969T21:13:20+0 is 
> -100 000 000 in milliseconds relative to unix Epoch.
> (-100 000 000 % 86 400 000) / 3 600 000 = -3,77 , so 3 hour is returned, and 
> it should be 21.
> For negative input value, it is required to add unit.multiplier.longValue() 
> (ie. 8 640 000 in hour case) to the value before dividing it.
> You can use this test (SqlOperatorBaseTest.java):
>   
> {code:java}
> @Test public void testExtractWithDatesBeforeUnixEpoch() {
>   tester.checkScalar(
>   "extract(hour from TIMESTAMP '1969-12-31 21:13:20')",
>   "21",
>   "BIGINT NOT NULL");
> }{code}
>  



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

Reply via email to