You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Danny Chen (Jira)" <ji...@apache.org> on 2020/04/15 09:55:00 UTC
[jira] [Resolved] (CALCITE-3881) SqlFunctions#addMonths yields
incorrect results in some corner case
[ https://issues.apache.org/jira/browse/CALCITE-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Danny Chen resolved CALCITE-3881.
---------------------------------
Fix Version/s: 1.23.0
Assignee: Danny Chen
Resolution: Fixed
Fixed in [43261e4|https://github.com/apache/calcite/commit/43261e4094a37ce23eb181a6a8f653dabc4db599], thanks for your PR, [~docete] !
> SqlFunctions#addMonths yields incorrect results in some corner case
> -------------------------------------------------------------------
>
> Key: CALCITE-3881
> URL: https://issues.apache.org/jira/browse/CALCITE-3881
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
> Affects Versions: avatica-1.16.0
> Reporter: Zhenghua Gao
> Assignee: Danny Chen
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.23.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> SqlFunctions#addMonths use DateTimeUtils#ymdToUnixDate to calculate the JDN(julian day number). But in some corner cases it yields incorrent results. The root cause is: the algorithm of DateTimeUtils#ymdToUnixDate requires reasonable month(1 to 12)[1], but SqlFunctions#addMonths may pass in a month out of the reasonable range.
> BTW: I didn't find the reference of the original paper of the algorithm, but an jdn explanation. Please correct me if anyone can find the original paper.
>
> The following case can reproduce the bug:
> addMonth('2019-09-01', 6) should yield '2020-03-01'
> {code:java}
> @Test public void testAddMonths() {
> checkAddMonths(2019, 9, 1, 2020, 3, 1, 6);
> } {code}
>
> [1] [http://www.cs.utsa.edu/~cs1063/projects/Spring2011/Project1/jdn-explanation.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)