Skip to content

Conversation

@ianton-ru
Copy link

@ianton-ru ianton-ru commented Oct 24, 2025

Changelog category (leave one):

  • New Feature

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Setting timezone_for_iceberg_timestamptz for Iceberg timestamptz type.

Documentation entry for user-facing changes

Solved ClickHouse#86641
Setting timezone_for_iceberg_timestamptz for Iceberg timestamptz type.
Possible values:

  • Any valid timezone, e.g. Europe/Berlin, UTC or `Zulu
  • Empty string to use session time zone.
    Default value is UTC.

CI/CD Options

Exclude tests:

  • Fast test
  • Integration Tests
  • Stateless tests
  • Stateful tests
  • Performance tests
  • All with ASAN
  • All with TSAN
  • All with MSAN
  • All with UBSAN
  • All with Coverage
  • All with Aarch64
  • All Regression
  • Disable CI Cache

Regression jobs to run:

  • Fast suites (mostly <1h)
  • Aggregate Functions (2h)
  • Alter (1.5h)
  • Benchmark (30m)
  • ClickHouse Keeper (1h)
  • Iceberg (2h)
  • LDAP (1h)
  • Parquet (1.5h)
  • RBAC (1.5h)
  • SSL Server (1h)
  • S3 (2h)
  • Tiered Storage (2h)

@github-actions
Copy link

github-actions bot commented Oct 24, 2025

Workflow [PR], commit [5ff409a]

DECLARE(Bool, export_merge_tree_part_overwrite_file_if_exists, false, R"(
Overwrite file if it already exists when exporting a merge tree part
)", 0) \
DECLARE(Timezone, timezone_for_iceberg_timestamptz, "UTC", R"(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to prepend all iceberg related settings with iceberg_? So this one would become iceberg_timezone_for_timestamptz

I understand that there is no uniformity and half of the settings begin with iceberg_, and rest are in complete disarray, but let's try to keep things in order

using Node = ActionsDAG::Node;

public:
IcebergSchemaProcessor(ContextPtr context_) : WithContext(context_) {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

explicit is missing

assert "Invalid time zone: Foo/Bar" in node.query_and_get_error(f"""
SELECT * FROM {CATALOG_NAME}.`{root_namespace}.{table_name}`
SETTINGS timezone_for_iceberg_timestamptz='Foo/Bar'
""")
Copy link
Member

@Enmk Enmk Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest checking timezone of the column with https://clickhouse.com/docs/sql-reference/functions/date-time-functions#timezoneOf , something like this:

for timezone in ('UTC', 'Europe/Berlin', 'Asia/Istanbul'):
    assert node.query(f"""
                      SELECT timezoneOf(timestamp), timezoneOf(timestamptz), 
                      SETTINGS timezone_for_iceberg_timestamptz='{timezone}'
                      """) == f"{timezone}\t{timezone}"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I check different cases here. Added comments.

Copy link
Member

@Enmk Enmk Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, but these tests check for serialization of the value to the string, NOT the timezone of the value. The setting may affect date time values in multiple ways:

  • changing the numerical value, but leaving timezone to UTC
  • leaving the numerical value intact, but changing the timezone value (=proper way to do it)

And these tests make no distinction between two... Also having proper timezone value is critical for determining day boundaries. Same UTC time value could be different days at different locations.

Copy link
Member

@Enmk Enmk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly Ok, but some changes required

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants