Thanks for raising this, Kevin.
Speaking as an iceberg-go maintainer, even though Go is the
implementation that has to move, I'd vote:
1. Writers SHOULD emit { "type": "int", "logicalType": "date" }.
2. Readers MUST accept both plain `int` and `int` annotated with
`logicalType: date`.
3. Keep the transform result type table as-is (`int` as the logical
Iceberg type). Don't change it to `date`. Add a separate, normative
manifest-encoding clause so projection and expression-evaluation
semantics that depend on the type model stay untouched.
Reasoning: when Java, PyIceberg, and Rust all write logical `date`,
that's the de facto wire format. Forcing them to switch to plain `int`
to match a literal reading of the transform table would churn three
implementations and leave every existing manifest "non-conforming"
forever. Aligning Go with the dominant writer convention costs one
implementation change (PR #915 already proposes it) and zero historical
churn.
The underlying ambiguity is that "result type" (logical Iceberg type)
and "Avro manifest encoding" (wire format) were conflated. Separating
them in spec text removes the ambiguity without changing the type
system.
Happy to drive the spec PR and then iceberg-go writer + reader
alignment.
Best,
Andrei
On Tue, May 19, 2026 at 5:45 PM Kevin Liu <[email protected]> wrote:
> Hi all,
>
> I'd like to invite the community to discuss a spec ambiguity in Apache
> Iceberg that has caused some confusion across implementations. We've seen
> this come up in Python, Rust, and now Go.
>
> The issue: the spec documents the `day` partition transform's result type
> as plain `int`, but Java, PyIceberg, and Rust all write manifest partition
> fields using Avro's logical `date` type. Go currently writes plain `int`,
> which is the strict reading of the spec. Since both forms have the same
> physical representation, the difference is only the Avro schema annotation
> -- but it's worth clarifying the spec so all implementations are aligned.
>
> The full analysis, including a breakdown of each implementation's
> writer/reader behavior and proposed resolution options, is here:
> https://github.com/apache/iceberg/issues/16414
>
> At a high level, the questions for the community are:
> 1. What should implementations write: Avro `int` (plain integer) or Avro
> `date` (integer with a date logical type)?
> 2. Should implementations be required to read both forms, or just
> encouraged to?
> 3. Should the spec's transform result type table be updated from `int` to
> `date`?
>
> I'd love to hear your thoughts. Thanks!
>
> Best,
> Kevin Liu
>
