I think you're right. AvroSchemaUtil has our conversions for interpreting
or producing schemas that are compatible with other Avro
producers/consumers. If an external Avro producer labels a `long` with
`local-timestamp-micros` then we aren't correctly mapping that into the
equivalent Iceberg type, a timestamp.

You could work around this by adding these files to a table with a `long`
instead of a `timestamp` field, but that requires a person to tell Iceberg
to read this file and how (add the file, use a `long` for the column type).
Since these files aren't produced by Iceberg and are a gray area in the
spec, we've avoided making strong guarantees about compatibility. I think
that's the right way to think about this: you can add non-Iceberg files to
a table, but that's at your own risk.

Ryan

On Thu, Jul 16, 2026 at 8:06 AM Russell Spitzer <[email protected]>
wrote:

> AvroSchemaUtil.convert necessarily has breaking changes when we add
> support for new types, in the past we have
> just changed the class when necessary and ignored the resulting behavior
> change. Is this a pattern we are ok with
> continuing?
>
> My gut answer here is yes. The old behavior is a bug and as long as we
> don't break any internal code by adding
> the new transform we are fine. We also shouldn't preserve legacy behaviors
> that we think are incorrect.
>
> There was a request on the PR to preserve this behavior in the API via a
> parameter so outside consumers
> can continue to use the old behavior but I don't really feel like that's a
> responsibility of the Iceberg project. I
> want to make sure I'm not ignoring any voices though so if you have strong
> feelings please let us know.
>
> The PR for LocalTimestamp Support:
> #17196 <https://github.com/apache/iceberg/pull/17196>
>
>
> *Previously*local-timestamp-micros => Long
>
>
> *Now:*local-timestamp-micros => TimestampType.withoutZone()
>
> Prior Art with Nano Timestamp
> #12455 <https://github.com/apache/iceberg/pull/12455>
>
>
> *Before Pr *NanoTimestamp => Long
>
>
> *After PR*NanoTimestamp => TimestampNanoType
>

Reply via email to