mateczagany commented on code in PR #29080:
URL: https://github.com/apache/flink/pull/29080#discussion_r3924552433


##########
flink-table/flink-table-runtime/src/main/java/org/apache/flink/table/runtime/functions/VariantCastUtils.java:
##########
@@ -180,12 +189,14 @@ private static String decimalTarget(int precision, int 
scale) {
     }
 
     /**
-     * Reads a timestamp variant as the target {@code TIMESTAMP}. A variant 
keeps microseconds, so
-     * fractional seconds beyond the target precision are truncated, the same 
as a regular {@code
-     * TIMESTAMP} to {@code TIMESTAMP(p)} cast.
+     * Reads a timestamp variant as the target {@code TIMESTAMP}. {@link 
Variant#getDateTime()}
+     * already accepts both the microsecond ({@link Variant.Type#TIMESTAMP}) 
and nanosecond ({@link
+     * Variant.Type#TIMESTAMP_NS}) encodings. Fractional seconds beyond the 
target precision are
+     * truncated, the same as a regular {@code TIMESTAMP} to {@code 
TIMESTAMP(p)} cast.
      */
     public static TimestampData toTimestamp(Variant variant, int precision) {
-        if (variant.getType() != Variant.Type.TIMESTAMP) {
+        final Variant.Type type = variant.getType();
+        if (type != Variant.Type.TIMESTAMP && type != 
Variant.Type.TIMESTAMP_NS) {
             throw unsupportedKind(variant, String.format("TIMESTAMP(%d)", 
precision));
         }
         return DateTimeUtils.truncate(

Review Comment:
   There seems to be a pre-existing bug here, as `DateTimeUtils.truncate` uses 
`Integer.toString(ts.toLocalDateTime().getNano())` to check the input's 
precision, which will drop the leading zeros.
   
   This results in casting a `TIMESTAMP_NS` value with fraction .000123456 to 
`TIMESTAMP(6)` keeping all its nine digits, as `Integer.toString()` will return 
a string with a length of 6.
   
   The following test would fail: 
   ```
     CastTestSpecBuilder.testCastTo(TIMESTAMP(6))
             .fromCase(
                     VARIANT(),
                     Variant.newBuilder().of(LocalDateTime.of(2020, 1, 1, 12, 
0, 0, 123_456)),
                     TimestampData.fromLocalDateTime(LocalDateTime.of(2020, 1, 
1, 12, 0, 0, 123_000)))
   ```
   
   with:
   
   ```
   Expected :2020-01-01T12:00:00.000123
   Actual   :2020-01-01T12:00:00.000123456
   ```
   
   Could you please fix the helper and include this test?



-- 
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]

Reply via email to