Vladsz83 commented on code in PR #11822:
URL: https://github.com/apache/ignite/pull/11822#discussion_r1995171466
##########
modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/exec/exp/IgniteRexBuilder.java:
##########
@@ -62,6 +74,97 @@ public IgniteRexBuilder(RelDataTypeFactory typeFactory) {
return super.makeLiteral(bd.setScale(type.getScale(),
RoundingMode.HALF_UP), type, typeName);
}
+ // Adjust temporal literals so that dates before 15.10.1582 would
match internal long representation.
+ // `RexLiteral#getValueAs(Class type)` uses
`DateTimeUtils#ymdToUnixDate(int year, int month, int day)` directly
+ // calculating epoch days. We use `new Date(long)` and `new
Timestampt(long)` in `TypeUtils#fromInternal(...)` and
+ // and `Date#getTime()` in `TypeUtils#toInternal(...)`. Classic
temporal types process the long value differently
+ // for dates before Gregorian calendar. `DateTimeUtils` does not. This
may cause +several weeks for old date literals.
+ if (o instanceof DateString)
Review Comment:
Also, a _long_ value doesn't say wheter it is already fixed or not. This is
a problem for repeating calls to/from. That is why we fix the issue where it
raises from and can be recognized. I belive, we should revise and refactor
temporal values convertation in future. For now, we have `DateValueUtils`,
`TypeUtils`, Calcite's `DateTimeUtils.` and Java's `Date#getTime()`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@ignite.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
