[jira] [Commented] (DERBY-6834) support for CURRENT_TIMESTAMP(precision) appears to be missing

[Rick Hillegas (JIRA)]

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

Rick Hillegas commented on DERBY-6834:
--

Note that CURRENT_TIME has the same optional precision argument, according to 
the Standard. If we improve one, then I think that we should improve the other.

The 2011 SQL Standard, part 2, section 6.32 (datetime value function) has this 
to say about the bounds and default for time and timestamp precisions:

SR 34) "If timePrecision is not specified, then 0 (zero) is implicit. If 
timestampPrecision is not specified,
then 6 is implicit."

SR 36) "The maximum value of timePrecision and the maximum value of 
timestampPrecision shall be the same implementation-defined value that is not 
less than 6. The values of timePrecision and timestampPrecision shall not be 
greater than that maximum value."

Derby violates SR 34 because the timestamp precision of 
System.currrentTimeMillis() is 3. Changing this to 6 would create a backward 
compatibility issue. Maybe it's a minor incompatibility since we are increasing 
the precision rather than decreasing it.

We can't conform completely because these rules say that CURRENT_TIME and 
CURRENT_TIMESTAMP must have the same maximum precision and that precision must 
be at least microseconds. But a Derby TIME value is an instance of  
java.sql.Time, which has millisecond precision.

If we pursue this enhancement, then I think that we should allow CURRENT_TIME 
and CURRENT_TIMESTAMP to have different maximum precisions, the maximum 
precison of CURRENT_TIMESTAMP should be 9 (the precision of System.nanoTime()), 
and we should raise an error if the user specifies a precision which is out of 
bounds.

Other thoughts?

Thanks,
-Rick

To conform to SR 36, we would need to raise an error if timestampPrecision is 
greater than 9.

> support for CURRENT_TIMESTAMP(precision) appears to be missing
> --
>
> Key: DERBY-6834
> URL: https://issues.apache.org/jira/browse/DERBY-6834
> Project: Derby
>  Issue Type: Improvement
>Reporter: Julian Reschke
> Attachments: firstTry.diff
>
>
> See 
> ,
>  , 
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6834) support for CURRENT_TIMESTAMP(precision) appears to be missing

[Bryan Pendleton (JIRA)]

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

Bryan Pendleton commented on DERBY-6834:


Ah, I see, thank you. Accepting (and ignoring) the 
optional parameter seems like a good intermediate step, 
and I agree it would be quite useful for portable 
applications. Thank you for clarifying.

> support for CURRENT_TIMESTAMP(precision) appears to be missing
> --
>
> Key: DERBY-6834
> URL: https://issues.apache.org/jira/browse/DERBY-6834
> Project: Derby
>  Issue Type: Improvement
>Reporter: Julian Reschke
>
> See 
> ,
>  , 
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6834) support for CURRENT_TIMESTAMP(precision) appears to be missing

[Julian Reschke (JIRA)]

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

Julian Reschke commented on DERBY-6834:
---

The main point is that the syntax should be accepted, so that Derby doesn't 
need to get a special case in code that is supposed to be generic.

> support for CURRENT_TIMESTAMP(precision) appears to be missing
> --
>
> Key: DERBY-6834
> URL: https://issues.apache.org/jira/browse/DERBY-6834
> Project: Derby
>  Issue Type: Improvement
>Reporter: Julian Reschke
>
> See 
> ,
>  , 
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6834) support for CURRENT_TIMESTAMP(precision) appears to be missing

[Rick Hillegas (JIRA)]

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

Rick Hillegas commented on DERBY-6834:
--

The syntax for CURRENT_TIMESTAMP() is defined in the 2011 SQL Standard, part 2, 
section 6.32 (datetime value function):

{noformat}
CURRENT_TIMESTAMP[ left_paren timestampPrecision right_paren ]

where timestampPrecision is an unsigned integer, the number of
decimal digits which follow the decimal point.
{noformat}

Right now, a Derby TIMESTAMP value is a java.sql.Timestamp, whose precision is 
nanoseconds. But the precision for CURRENT_TIMESTAMP() is actually coarser 
because Derby calculates the current time using System.currentTimeMillis(). The 
precision could be increased to nanoseconds if Derby called System.nanoTime() 
instead. I would be interested in suggestions about how a pure Java application 
like Derby could get the current time at a greater precision than nanoseconds. 
Thanks.


> support for CURRENT_TIMESTAMP(precision) appears to be missing
> --
>
> Key: DERBY-6834
> URL: https://issues.apache.org/jira/browse/DERBY-6834
> Project: Derby
>  Issue Type: Improvement
>Reporter: Julian Reschke
>
> See 
> ,
>  , 
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6834) support for CURRENT_TIMESTAMP(precision) appears to be missing

[Bryan Pendleton (JIRA)]

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

Bryan Pendleton commented on DERBY-6834:


To be explicit, what would be different about your new proposed function,
compared to Derby's existing CURRENT_TIMESTAMP function.

http://db.apache.org/derby/docs/10.11/ref/rrefsqlj15866.html

> support for CURRENT_TIMESTAMP(precision) appears to be missing
> --
>
> Key: DERBY-6834
> URL: https://issues.apache.org/jira/browse/DERBY-6834
> Project: Derby
>  Issue Type: Improvement
>Reporter: Julian Reschke
>
> See 
> ,
>  , 
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)