[
https://issues.apache.org/jira/browse/DERBY-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905167#action_12905167
]
C.S. Nirmal J. Fernando commented on DERBY-4625:
------------------------------------------------
Hi Knut,
Thanks for reviewing the patch.
>The constant SQLTimestamp.FRACTION_TO_NANO is used in
>SQLChar.setValue(Timestamp,Calendar). I think changing it from 1000 to 1 may
>make the calculations in >SQLChar become wrong. (If we fix DERBY-4626 that
>code will probably go away, though.)
Without changing 1000 to 1 we can't get the expected result. I am wondering
whether there are test cases which is addressed this setValue(..) function. If
so since I did not find any regression failures regarding that, can't we
conclude that the calculations of SQLChar are still correct?
Thanks.
> TIMESTAMP function doesn't accept nanoseconds
> ---------------------------------------------
>
> Key: DERBY-4625
> URL: https://issues.apache.org/jira/browse/DERBY-4625
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0
> Reporter: Knut Anders Hatlen
> Assignee: C.S. Nirmal J. Fernando
> Priority: Minor
> Attachments: derby-4625-1.diff
>
>
> The TIMESTAMP function fails if the string argument specifies the number of
> nanoseconds. It works if the argument is limited to microsecond resolution.
> ij> values timestamp('2010-04-21 12:00:00.123456');
> 1
> --------------------------
> 2010-04-21 12:00:00.123456
> 1 row selected
> ij> values timestamp('2010-04-21 12:00:00.123456789');
> ERROR 22008: '2010-04-21 12:00:00.123456789' is an invalid argument to the
> timestamp function.
> Since Derby (and JDBC) supports nanosecond resolution, the TIMESTAMP function
> should also support it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
