Change UTC_TIME_ZONE constant from "+00:00" to "UTC" for compatibility with Snowflake

[vovacf201]

Apache Iceberg Rust version

Latest

Describe the bug

Arrow in iceberg-rust uses "+00:00" constant as UTC which is not compatible with Snowflake.
https://github.com/apache/iceberg-rust/blob/main/crates/iceberg/src/arrow/schema.rs#L45

Expected behavior

Proposal is to change it to "UTC" (how it's done in Spark)

Willingness to contribute

Happy to contribute with community review

[blackmwk]

Thanks @vovacf201 for bringing this up. I'm not familiar with Snowflake, could you elaborate how Snowflake handles it?

[vovacf201]

@blackmwk Snowflake just rejects parquet files with "+00:00" tz as invalid and expects "UTC". From Spark spec seems both strings are valid representations of UTC. I wonder if we can switch to "UTC" constant or make it configurable.

From Spark spec:

tz Column or literal string
A string detailing the time zone ID that the input should be adjusted to. It should be in the format of either region-based zone IDs or zone offsets. Region IDs must have the form ‘area/city’, such as ‘America/Los_Angeles’. Zone offsets must be in the format ‘(+|-)HH:mm’, for example ‘-08:00’ or ‘+01:00’. Also ‘UTC’ and ‘Z’ are supported as aliases of ‘+00:00’. Other short names are not recommended to use because they can be ambiguous.

[kevinjqliu]

@vovacf201 do you mind sharing your table definition? And the setup including where this breaks.

[kevinjqliu]

So the issue is likely in Snowflake's Arrow schema reader — specifically how it deserializes the embedded Arrow schema from the Parquet footer and maps the timezone annotation to a Snowflake type. Snowflake is probably reading the Arrow metadata to get richer type information (like timezone), and its Arrow schema parser doesn't recognize "+00:00" as a valid timezone.

The native Parquet schema itself doesn't store a timezone string at all — it just has isAdjustedToUTC as a boolean. So the "+00:00" string can only be coming from the Arrow schema embedded in the footer, which means the failure point is in how Snowflake processes that Arrow metadata.

This also explains why Spark works fine — Spark writes "UTC" in its embedded Arrow schema, so Snowflake's Arrow reader handles it without issue.

From claude, this makes sense. The issue is with reading the schema annotation and not from reading the parquet file with timestamptz

I wonder if we can switch to "UTC" constant or make it configurable.

I think this is reasonable. Or we can change the default to "UTC"

[blackmwk]

I think it's reasonable to change to "UTC" if spark is compatible with both. But I still don't understand why it's not compatible with snowflake? This constant is used when converting iceberg schema to arrow schema, @vovacf201 could you elaborate how it can fail snowflake?

[blackmwk]

@blackmwk Snowflake just rejects parquet files with "+00:00" tz as invalid and expects "UTC". From Spark spec seems both strings are valid representations of UTC. I wonder if we can switch to "UTC" constant or make it configurable.

From Spark spec:

tz Column or literal string
A string detailing the time zone ID that the input should be adjusted to. It should be in the format of either region-based zone IDs or zone offsets. Region IDs must have the form ‘area/city’, such as ‘America/Los_Angeles’. Zone offsets must be in the format ‘(+|-)HH:mm’, for example ‘-08:00’ or ‘+01:00’. Also ‘UTC’ and ‘Z’ are supported as aliases of ‘+00:00’. Other short names are not recommended to use because they can be ambiguous.

Oh, do you mean that it will leads to saving "UTC" in parquet file?

[vovacf201]

@blackmwk my understanding it stored in parquet footer which Snowflake can't read

[blackmwk]

Thanks for the explaination, I'm fine with this change.

[vovacf201]

we recently tested latest version of SnowFlake and no issues anymore, so I'm closing this because we can just switch to latest