Follow-up to #1863 and #2448.
table.local-time-zone accepts fixed-offset ids such as GMT-08:00, and Flink's own validation message recommends that form. The native Flink_UnixTimestamp resolves its zone id by exact-match lookup against the IANA time zone database via chrono-tz, which carries no GMT±HH:MM entries, so those ids cannot be resolved natively.
#2448 rejects them at plan time, so the Calc falls back to Flink and returns correct results. That closes the correctness hole, since before it the id reached the native call and failed there, past the point where any fallback remained. But it also means a session on a fixed offset gets no native acceleration for any Calc containing UNIX_TIMESTAMP.
141 of the 745 zone ids Flink's validator accepts are in this family. It is reachable without any explicit configuration too: the default value resolves to ZoneId.systemDefault(), so a TaskManager running with TZ=GMT-08:00 lands there silently.
Idea: teach flink_unix_timestamp to parse GMT±HH:MM into an explicit fixed offset, and drop the offset family from the plan-time gate. parse_datetime and resolve_offset_secs are both typed on chrono_tz::Tz, so this needs a generalization over Tz and a fixed offset. The parser in #2409 was validated differentially against SimpleDateFormat, and the offset path should be validated the same way.
The plan-time gate stays regardless. The legacy SystemV/* ids are in ZoneId.getAvailableZoneIds() but absent from chrono-tz, so they still need to fall back.
One alternative was considered and rejected: mapping fixed offsets onto chrono-tz's Etc/GMT∓N names on the Java side, avoiding any native change. POSIX inverts the sign there, so Etc/GMT+8 is UTC−8, and an error would ship timestamps silently wrong by twice the offset rather than merely unaccelerated. Half-hour offsets such as GMT+05:30 have no Etc/ equivalent either.
Follow-up to #1863 and #2448.
table.local-time-zoneaccepts fixed-offset ids such asGMT-08:00, and Flink's own validation message recommends that form. The nativeFlink_UnixTimestampresolves its zone id by exact-match lookup against the IANA time zone database via chrono-tz, which carries noGMT±HH:MMentries, so those ids cannot be resolved natively.#2448 rejects them at plan time, so the Calc falls back to Flink and returns correct results. That closes the correctness hole, since before it the id reached the native call and failed there, past the point where any fallback remained. But it also means a session on a fixed offset gets no native acceleration for any Calc containing
UNIX_TIMESTAMP.141 of the 745 zone ids Flink's validator accepts are in this family. It is reachable without any explicit configuration too: the default value resolves to
ZoneId.systemDefault(), so a TaskManager running withTZ=GMT-08:00lands there silently.Idea: teach
flink_unix_timestampto parseGMT±HH:MMinto an explicit fixed offset, and drop the offset family from the plan-time gate.parse_datetimeandresolve_offset_secsare both typed onchrono_tz::Tz, so this needs a generalization overTzand a fixed offset. The parser in #2409 was validated differentially againstSimpleDateFormat, and the offset path should be validated the same way.The plan-time gate stays regardless. The legacy
SystemV/*ids are inZoneId.getAvailableZoneIds()but absent from chrono-tz, so they still need to fall back.One alternative was considered and rejected: mapping fixed offsets onto chrono-tz's
Etc/GMT∓Nnames on the Java side, avoiding any native change. POSIX inverts the sign there, soEtc/GMT+8is UTC−8, and an error would ship timestamps silently wrong by twice the offset rather than merely unaccelerated. Half-hour offsets such asGMT+05:30have noEtc/equivalent either.