Skip to content

Commit 8d419ed

Browse files
committed
Fix current_timestamp failure due to improper rounding
When the number of nanoseconds in the current instant is such that it needs to round up to the nearest millisecond, the calculation doesn't properly compute the carryover.
1 parent 17086d9 commit 8d419ed

File tree

1 file changed

+7
-4
lines changed

1 file changed

+7
-4
lines changed

core/trino-main/src/main/java/io/trino/type/DateTimes.java

Lines changed: 7 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -648,10 +648,13 @@ public static LongTimestampWithTimeZone longTimestampWithTimeZone(long precision
648648
{
649649
checkArgument(precision <= TimestampWithTimeZoneType.MAX_PRECISION, "Precision is out of range");
650650

651-
return LongTimestampWithTimeZone.fromEpochMillisAndFraction(
652-
start.toEpochMilli(),
653-
(int) round((start.getNano() % NANOSECONDS_PER_MILLISECOND) * PICOSECONDS_PER_NANOSECOND, (int) (TimestampWithTimeZoneType.MAX_PRECISION - precision)),
654-
timeZoneKey);
651+
long epochMilli = start.toEpochMilli();
652+
int picosOfMilli = (int) round((start.getNano() % NANOSECONDS_PER_MILLISECOND) * PICOSECONDS_PER_NANOSECOND, (int) (TimestampWithTimeZoneType.MAX_PRECISION - precision));
653+
if (picosOfMilli == PICOSECONDS_PER_MILLISECOND) {
654+
epochMilli++;
655+
picosOfMilli = 0;
656+
}
657+
return LongTimestampWithTimeZone.fromEpochMillisAndFraction(epochMilli, picosOfMilli, timeZoneKey);
655658
}
656659

657660
public static LongTimestampWithTimeZone longTimestampWithTimeZone(long epochSecond, long fractionInPicos, ZoneId zoneId)

0 commit comments

Comments
 (0)