juntaozhang opened a new issue, #7151: URL: https://github.com/apache/paimon/issues/7151
### Search before asking - [x] I searched in the [issues](https://github.com/apache/paimon/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. ```java @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 (https://github.com/apache/amoro/issues/4066). I'm wondering if we should simply use the milliseconds directly like this: ```java @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? - [x] I'm willing to submit a PR! -- 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]
