Skip to content

Commit

Permalink
Fix current_timestamp failure due to improper rounding
Browse files Browse the repository at this point in the history
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.
martint committed May 12, 2023

Verified

This commit was signed with the committer’s verified signature.
tmpfs muji
1 parent 17086d9 commit 8d419ed
Showing 1 changed file with 7 additions and 4 deletions.
11 changes: 7 additions & 4 deletions core/trino-main/src/main/java/io/trino/type/DateTimes.java
Original file line number Diff line number Diff line change
@@ -648,10 +648,13 @@ public static LongTimestampWithTimeZone longTimestampWithTimeZone(long precision
{
checkArgument(precision <= TimestampWithTimeZoneType.MAX_PRECISION, "Precision is out of range");

return LongTimestampWithTimeZone.fromEpochMillisAndFraction(
start.toEpochMilli(),
(int) round((start.getNano() % NANOSECONDS_PER_MILLISECOND) * PICOSECONDS_PER_NANOSECOND, (int) (TimestampWithTimeZoneType.MAX_PRECISION - precision)),
timeZoneKey);
long epochMilli = start.toEpochMilli();
int picosOfMilli = (int) round((start.getNano() % NANOSECONDS_PER_MILLISECOND) * PICOSECONDS_PER_NANOSECOND, (int) (TimestampWithTimeZoneType.MAX_PRECISION - precision));
if (picosOfMilli == PICOSECONDS_PER_MILLISECOND) {
epochMilli++;
picosOfMilli = 0;
}
return LongTimestampWithTimeZone.fromEpochMillisAndFraction(epochMilli, picosOfMilli, timeZoneKey);
}

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

0 comments on commit 8d419ed

Please sign in to comment.