rionmonster commented on code in PR #27650:
URL: https://github.com/apache/flink/pull/27650#discussion_r2847144982
##########
flink-table/flink-table-common/src/main/java/org/apache/flink/table/expressions/ValueLiteralExpression.java:
##########
@@ -283,11 +284,14 @@ public String asSerializableString(SqlFactory sqlFactory)
{
localDateTime.toLocalTime().format(DateTimeFormatter.ISO_LOCAL_TIME));
case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
final Instant instant = getValueAs(Instant.class).get();
- if (instant.getNano() % 1_000_000 != 0) {
- throw new TableException(
- "Maximum precision for
TIMESTAMP_WITH_LOCAL_TIME_ZONE literals is '3'");
- }
- return String.format("TO_TIMESTAMP_LTZ(%d, %d)",
instant.toEpochMilli(), 3);
+ final LocalDateTime localDateTimeWithTimeZone =
+ instant.atOffset(ZoneOffset.UTC).toLocalDateTime();
+ return String.format(
+ "TIMESTAMP WITH LOCAL TIME ZONE '%s %s'",
Review Comment:
@twalthr
> There are two hard problems in programming, naming and time semantics.
Yes absolutely — choosing an issue to tackle that involves both of them
going in relatively blind was probably not the best decision either. 😄
I figured that the issue would likely be quite a bit more involved than
originally expected. It seems tied to a cascade of other related issues as you
mentioned. I noticed that there was [a
PR](https://github.com/apache/flink/pull/10776) related to the issue that you
shared to extend the precision for `TO_TIMESTAMP` from 3 to 9, however the
deeper issue in FLINK-15528 to support higher row-level timestamp precision may
likely need to be tackled first.
Given the timezone concern that you mentioned — Instant being in UTC while
`TIMESTAMP_LTZ` literals are session-local — would a CAST-based approach work
here as a targeted fix? Something like emitting the following (or similar) from
`asSerializableString()` instead of the raw literal itself?
```
CAST(TIMESTAMP '...' AS TIMESTAMP(9) WITH LOCAL TIME ZONE)
```
If that worked I suppose it would side-step some of the current precision
issues. Either way, I'm happy to pivot to that approach, or if you'd prefer to
defer this until the upstream precision work (e.g.,
[FLINK-14925](https://issues.apache.org/jira/browse/FLINK-14925),
[FLINK-15528](https://issues.apache.org/jira/browse/FLINK-15528)) lands, I
understand — just let me know how you'd like to proceed.
Thanks again and appreciate the feedback!
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
