[Feature] `PojoDataFileMeta.creationTimeEpochMillis()` may mislead user about the creation time of the file

[juntaozhang]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

PojoDataFileMeta.creationTimeEpochMillis() handling logic:

1. Converts the timestamp to LocalDateTime using toLocalDateTime() (which ignores timezone information)
2. Then treats this LocalDateTime as if it were in the system default timezone
3. Finally converts it back to epoch milliseconds

This double conversion causes timezone-related errors, especially when the system default timezone is not UTC.

@Override
public long creationTimeEpochMillis() {
    return creationTime
            .toLocalDateTime()
            .atZone(ZoneId.systemDefault())
            .toInstant()
            .toEpochMilli();
}

According to the Javadoc of the Timestamp class, the millisecond field already stores the number of milliseconds since the epoch (1970-01-01 00:00:00 UTC).

So millisecond in creationTime is UTC will be converted to Asia/Shanghai timezone millisecond,
which will 8h shift to the left.

This approach can be confusing for user (apache/amoro#4066). I'm wondering if we should simply use the milliseconds directly like this:

@Override
public long creationTimeEpochMillis() {
    return creationTime.getTime();
}

Please let me know if I'm understanding this correctly or if there are any issues with this approach.

Solution

No response

Anything else?

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!