### Summary On GitLab 19.4.x Cloud Native (Helm chart / CNG images), a merge request shows as having merge conflicts, and cannot be merged from the UI, whenever the MR author's stored timezone is a legacy IANA link name. That includes the "Kyiv", "Greenland", and "Rangoon" dropdown entries, and any other legacy name Rails accepts, such as `Israel` or `US/Eastern` (113 names in total). The branches merge cleanly; the failure is a Gitaly RPC error being misreported as a conflict. ### Steps to reproduce 1. Deploy GitLab 19.4.x using the Helm chart (CNG images). 2. Set a user's profile timezone to "Kyiv" (or "Greenland" or "Rangoon"). 3. As that user, open or refresh a merge request with no real conflicts. 4. Observe the MR is marked as having merge conflicts and the "Merge" button is blocked. ### What is the current *bug* behavior? The MR is flagged as unmergeable due to a conflict, even though the source and target branches merge cleanly. Any Gitaly operation that sends the user's timezone (merge, mergeability check / merge ref, squash, web UI commits) fails. ### What is the expected *correct* behavior? The MR should merge normally regardless of the author's selected timezone. A Gitaly RPC failure should not be displayed as a merge conflict. ### Relevant logs and/or screenshots Gitaly raises `unknown time zone Europe/Kiev`. GitLab shows this as a merge conflict instead of an error. <details> <summary>Image comparison confirming the missing tzdata-legacy package in Gitaly's base image</summary> | Image | Base | tzdata-legacy | Europe/Kiev | |---|---|---|---| | `registry.gitlab.com/gitlab-org/build/cng/gitaly:v19.3.3` | Debian 12 bookworm | n/a | present (symlink to Kyiv) | | `registry.gitlab.com/gitlab-org/build/cng/gitaly:v19.4.1` | Debian 13 trixie | not installed | missing | | `registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ee:v19.4.1` | Debian 13 trixie | installed | present | Checking all 136 ActiveSupport `MAPPING` identifiers against `gitaly:v19.4.1`, exactly three are missing: `America/Godthab`, `Europe/Kiev`, `Asia/Rangoon`. Environment reported: GitLab 19.4.1-ee, Rails 7.2.3.1. </details> ### Root cause Rails 7.2 ActiveSupport maps these display names to legacy IANA link names ("Kyiv" → "Europe/Kiev", "Greenland" → "America/Godthab", "Rangoon" → "Asia/Rangoon"). The profile dropdown stores the resulting `tzinfo.identifier`, so `user_preferences.timezone` ends up holding the legacy name. `Gitlab::Git::User#convert_timezone` passes this value to Gitaly unchanged. Gitaly resolves it via Go's `time.LoadLocation` against the system zoneinfo database (no embedded tzdata, `ZONEINFO` unset), which fails because the link is missing. <details> <summary>Why the link is missing in CNG's Gitaly image</summary> gitlab-org/build/CNG!3052 (milestone 19.4) moved CNG images from Debian bookworm to trixie. Trixie moved legacy timezone links into the separate `tzdata-legacy` package. That MR added `tzdata-legacy` to `gitlab-rails/Dockerfile.erb` only, not to `gitlab-base` (the base image Gitaly's image is built from). So `gitlab-webservice` has the legacy links but Gitaly does not. Rails main already maps Kyiv → Europe/Kyiv, Greenland → America/Nuuk, Rangoon → Asia/Yangon; Rails 8.1.0 still uses the legacy Europe/Kiev mapping. The Linux package (Omnibus) Docker image has shipped `tzdata-legacy` since 18.5 (gitlab-org/omnibus-gitlab!8759) and is not affected the same way; Linux package installs directly on a host depend on whether that host has `tzdata-legacy` (see #571698). </details> <details> <summary>Why this shows as a "conflict" instead of an error</summary> Gitaly returns `InvalidArgument`, which `Gitlab::Git::WrapsGitalyErrors` raises as `ArgumentError`. `MergeRequests::MergeToRefService` rescues it and returns an error result. `MergeRequests::MergeabilityCheckService#update_merge_status` then calls `mark_as_unmergeable` on any merge-to-ref failure. `CheckConflictStatusService` reports `cannot_be_merged?` as a conflict. There is no code path that distinguishes a real conflict from an RPC error. </details> ### Workaround Change the MR author's timezone to a non-affected zone with the same UTC offset (or to UTC), then trigger a mergeability recheck, for example by pushing a commit. Alternatively, install `tzdata-legacy` in the Gitaly container. ### Proposed fix Fix both sides: - **Rails** (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257897): translate all 113 legacy links to their canonical zones in `Gitlab::Git::User#convert_timezone` before sending them to Gitaly, for example `Europe/Kiev` → `Europe/Kyiv` and `Israel` → `Asia/Jerusalem`. No data migration, no UI change, and it works for every install type. - **CNG:** add `tzdata-legacy` to the Gitaly image, matching the webservice image. <details> <summary>Why TZInfo's canonical_identifier can't be used instead</summary> `TZInfo::Timezone#canonical_identifier` would normally resolve a link name to its canonical target, but with the system zoneinfo data source it returns the link name unchanged, so it cannot replace the explicit translation above. </details> Follow-up (tracked separately): - Stop reporting Gitaly RPC errors as merge conflicts (separate issue). ### Related - #571698 (open — Europe/Kyiv missing after 18.4, tzdata-legacy) - #490299 (closed — Ubuntu 24.04) - #435965 (closed — "unknown time zone" on web commits) - gitlab-org/gitaly#3655 - gitlab-org/build/CNG!3052 - gitlab-org/omnibus-gitlab!8759