@Rocky, I wanted to check if there has been an intentional behavior change around legacy / deprecated IANA timezone aliases in

CONVERT_TZ

. We are currently on StarRocks 4.0.11. In 4.0.11, aliases like

US/Eastern

resolve correctly in row/CTE-based expressions and match the canonical timezone

America/New_York

. For example, on 4.0.11:

WITH cases AS (
 SELECT 'winter' AS season, '2024-01-15 12:00:00' AS utc_ts
 UNION ALL
 SELECT 'summer', '2024-07-15 12:00:00'
)
SELECT
 season,
 utc_ts,
 CONVERT_TZ(utc_ts, 'UTC', 'US/Eastern') AS alias_eastern,
 CONVERT_TZ(utc_ts, 'UTC', 'America/New_York') AS canonical_new_york
FROM cases;Result:
+--------+---------------------+---------------------+---------------------+
| season | utc_ts       | alias_eastern    | canonical_new_york |
+--------+---------------------+---------------------+---------------------+
| winter | 2024-01-15 12:00:00 | 2024-01-15 07:00:00 | 2024-01-15 07:00:00 |
| summer | 2024-07-15 12:00:00 | 2024-07-15 08:00:00 | 2024-07-15 08:00:00 |
+--------+---------------------+---------------------+---------------------+

But on 4.1.x, the same query returns

NULL

for the legacy alias, while the canonical timezone continues to work:

+--------+---------------------+---------------+---------------------+
| season | utc_ts       | alias_eastern | canonical_new_york |
+--------+---------------------+---------------+---------------------+
| winter | 2024-01-15 12:00:00 | NULL     | 2024-01-15 07:00:00 |
| summer | 2024-07-15 12:00:00 | NULL     | 2024-07-15 08:00:00 |
+--------+---------------------+---------------+---------------------+I

also noticed similar behavior with

Asia/Calcutta

vs

Asia/Kolkata

.The legacy alias returns

NULL

in row/CTE-based expressions, while the canonical zone works. Was support for legacy IANA aliases like

US/Eastern

and

Asia/Calcutta

intentionally changed in 4.1.x?

Based on recent StarRocks development and community reports, the behavior you are seeing in StarRocks 4.1.x is not an intentional policy change to remove support for legacy IANA aliases. Rather, it appears to be a known issue or regression in how the engine (BE) resolves certain timezone names in the 4.1.x release line. Key Observations * Regression from 4.0.11: In StarRocks 4.0.11 and earlier, legacy aliases like

US/Eastern

and

Asia/Calcutta

were correctly resolved to their canonical counterparts (

America/New_York

and

Asia/Kolkata

). * Resolution Issue in 4.1.x: In StarRocks 4.1.x, the Backend (BE) engine fails to match these aliases during row-level expression evaluation, leading the

CONVERT_TZ

function to return

NULL

(as it does for any invalid timezone string). * Related Issues: Similar behavior has been reported for other timezones like

Africa/Casablanca

and

Africa/El_Aaiun

in recent versions. These issues were tracked in the StarRocks community as being related to the underlying timezone library (cctz) and how StarRocks initializes its timezone cache. Root Cause While not officially documented as a "behavior change," internal changes in StarRocks 4.1 (including updates to system dependencies and the query execution path) have made the timezone resolution stricter or caused it to lose track of some IANA "Links" (aliases). Specifically: * A bug fix (tracked in PRs like #70671) involved upgrading the

cctz

library from v2.3 to v2.4 to fix certain timezone parsing errors. * The fact that it works for canonical names but fails for aliases suggests that the link-resolution logic in the BE is currently broken for these specific names in your version. Recommended Action 1. Use Canonical Names: To ensure compatibility across 4.0 and 4.1, it is best practice to use the canonical IANA names: * Use

America/New_York

instead of

US/Eastern

. * Use

Asia/Kolkata

instead of

Asia/Calcutta

. 2. Monitor for Fixes: Check the release notes for upcoming 4.1.x patch releases (e.g., 4.1.2+). There have been active commits (such as #66817) to improve timezone cache handling and fix "not found" errors for specific zones. 3. Report to Community: Since you have a reproducible case for

US/Eastern

and

Asia/Calcutta

in a CTE, I recommend opening a GitHub issue or posting in the StarRocks Slack. This helps the maintainers verify if these specific aliases were missed in recent

cctz

/

tzdata

fixes. Authoritative Sources: * StarRocks #70671: CONVERT_TZ returns NULL for certain timezones * StarRocks #74035: convert_tz incorrect results with old tzdata References • sql-reference/sql-functions/date-time-functions/convert_tz.md • sql-reference/How_to_Write_Functions_Documentation.md • administration/management/timezone.md • sql-reference/sql-functions/date-time-functions/current_timezone.md • sql-reference/System_variable.md • sql-reference/sql-functions/date-time-functions/to_datetime.md