wombatu-kun opened a new pull request, #16620: URL: https://github.com/apache/iceberg/pull/16620
`HiveOperationsBase.newHmsTable` and `HiveViewOperations.newHMSView` set the HMS `createTime` and `lastAccessTime` as `(int) currentTimeMillis / 1000`. Java operator precedence makes this `((int) currentTimeMillis) / 1000`, so the 64-bit epoch-millis value is truncated to 32 bits before the division. The resulting seconds value is nonsensical: it lands around January 1970 and is negative for part of every ~49-day wrap cycle, instead of the intended creation time. The fix parenthesizes the division as `(int) (currentTimeMillis / 1000)`; epoch seconds fit in a signed int until 2038, so the value is correct again. HMS overwrites `createTime` server-side on create, so the persisted and observable symptom is `lastAccessTime`, which HMS stores exactly as the client sends it. A garbage `lastAccessTime` shows up in `DESCRIBE FORMATTED` and can mislead staleness or retention tooling that reads `TBLS.LAST_ACCESS_TIME`. ## Tests Added regression coverage that creates a table and a view through `HiveCatalog` and asserts the HMS `lastAccessTime` reflects the current epoch second: `TestHiveCatalog.newTableSetsCurrentHmsLastAccessTime` and `TestHiveViewCatalog.newViewSetsCurrentHmsLastAccessTime`. Both fail before the fix (the value lands near 1970) and pass after it. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
