[
https://issues.apache.org/jira/browse/CALCITE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093829#comment-16093829
]
Julian Hyde commented on CALCITE-1884:
--------------------------------------
It's difficult to make claims about the behavior of java.sql.Date because a lot
of operations (e.g. extracting days of the week, converting to a string) occur
in the context of a calendar, usually GregorialCalendar, and/or a locale.
One can run a SQL query, convert the results to a string, and examine the
results in a context where no Java is involved. The SQL standard is written in
those terms. As I said in CALCITE-1832, It follows from the SQL standard that
{{CAST(DATE '1752-09-20' - INTERVAL '10' DAY AS VARCHAR(10))}} should return
the string '1752-09-10'. I think your change breaks that.
If you want a function that is consistent with Java's internal representation
of dates, maybe you need a new function. That was not the goal of this function.
> DateTimeUtils produces incorrect results for days before Gregorian cutovers
> ---------------------------------------------------------------------------
>
> Key: CALCITE-1884
> URL: https://issues.apache.org/jira/browse/CALCITE-1884
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: 1.13.0
> Reporter: Haohui Mai
> Assignee: Haohui Mai
>
> dateStringToUnixDate() / unixDateToString() do not return consistent result.
> The following test fails:
> {noformat}
> @Test public void testUnixDate() {
> int days = DateTimeUtils.dateStringToUnixDate("1500-04-30");
> assertEquals("1500-04-30", DateTimeUtils.unixDateToString(days));
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
