Iceberg partition directory name not consistent with Iceberg Java

[PingLiuPing]

Describe the problem you faced

create table timestamp(c1 int, c2 TIMESTAMP) with (format='PARQUET', partitioning=ARRAY['c2']);
insert into timestamp values(1, TIMESTAMP '2025-07-11 15:01:00.000');
select * from "timestamp$files";

The file_path is file:/iceberg_data/HIVE/iceberg/timestamp/data/c2=2025-07-11T14%3A01/67960c5e-661a-409a-a319-75a37732514f.parquet

Note that the the partition value has been changed to 2025-07-11T14%3A01 which omits the zero seconds and milli seconds part.

But in Iceberg Java, for example in testTimestampWithoutZoneHumanString we can easily verify this value and the result is 2025-07-11T15:01:00 which keeps the zero seconds part.

We can also verify this on Trino which also keeps the zero seconds part.

• A clear and concise description of the problem.
• Was this working before or is this a first try?
• If this worked before, then what has changed that recently?
• Provide table DDLs and EXPLAIN ANALYZE for your Presto queries.

Environment Description

• Presto version used:
• Storage (HDFS/S3/GCS..):
• Data source and connectors or catalogs used:
• Deployment (Cloud or On-prem):
• Pastebin link to the complete debug logs:

Steps To Reproduce

Steps to reproduce the behavior:
1.
2.
3.
4.

Expected behavior

Additional context

Stacktrace

[PingLiuPing]

@hantangwangd , Just wonder are you aware of this? Do you know the history of this implementation? Thank you very much.

[hantangwangd]

@PingLiuPing After checking the code in detail, I found the core reason is that we're relying on different Iceberg versions. Currently we're on Iceberg1.6.1 while trino use 1.9.2, and the implementation of method TransformUtil.humanTimestampWithoutZone was changed right after version1.6.1, see apache/iceberg#9008. That's why it's generating a different string.

I'm a little concerned that this change might cause data written by a previously Iceberg version to be unreadable or incorrectly queried by newer versions of Iceberg. However, the release notes of Iceberg1.7.0 don't mention anything about backward compatibility issues regarding this change, see here. I'll do some tests to confirm this issue.

[hantangwangd]

It appears that after upgrading to Iceberg version 1.7.0, it keeps backward compatible with partition paths generated by earlier versions. Meanwhile, the forward compatibility seems to be kept as well, that is, Iceberg 1.6.0 can read the data written by other engines which use newer versions of Iceberg correctly.

@PingLiuPing Have you run into any actual problems because of this change?

[PingLiuPing]

@hantangwangd Thank you so much. I didn't run into any problems, it's just I'm implementing the native iceberg writer and initially I compare the partition name with Presto and trailing the zero seconds according to Presto's convention. But when I occasionally looking at Iceberg java code on toHumanString and write some corner cases there I found the differences.

[hantangwangd]

@PingLiuPing Got it. I believe this is not a problem. Iceberg relies on the metadata stored in the manifest and data files for file planning and filtering -- it doesn't use the physical storage path for this calculations. So, it seems that we could be able to safely ignore this.