GitLab-CE Docker upgrade to 18.0.0 failed: "ArgumentError: Invalid Timezone: US/Pacific"

How to Use GitLab Migrations
1

I’ve been running the gitlab-ce Docker image for a while now at home and at work. Upon pulling v18.0.0 today, both installations failed to start up. I ran docker logs -f gitlab | tee /tmp/gitlab.log while it tried to start up. Database migration failed:

Recipe: gitlab::database_migrations
  * ruby_block[check remote PG version] action nothing (skipped due to action :nothing)
  * rails_migration[gitlab-rails] action run[2025-05-17T00:05:19+00:00] WARN: gitlab-rails does not have a log_group or default logdir mode defined. Setting to 0700.

    * bash_hide_env[migrate gitlab-rails database] action run
      [execute] rake aborted!
                ArgumentError: Invalid Timezone: US/Pacific
                /opt/gitlab/embedded/service/gitlab-rails/config/initializers/time_zone.rb:3:in `<top (required)>'
                /opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:7:in `<top (required)>'
                <internal:/opt/gitlab/embedded/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
                <internal:/opt/gitlab/embedded/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
                /opt/gitlab/embedded/bin/bundle:25:in `load'
                /opt/gitlab/embedded/bin/bundle:25:in `<main>'
                Tasks: TOP => gitlab:db:configure => environment
                (See full trace by running task with --trace)
      
      ================================================================================
      Error executing action `run` on resource 'bash_hide_env[migrate gitlab-rails database]'
      ================================================================================

I had previously set the timezone in /etc/gitlab/gitlab.rb within the container, but I commented that out and moved the setting to docker-compose.yml as follows:

    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.alfter.us'
        gitlab_rails['time_zone'] = 'America/Los_Angeles'

I really don’t care for the America/* timezone options and would rather use US/* (in my case, US/Pacific). Nobody calls this the Los Angeles timezone; it’s the Pacific timezone. Why the GitLab upgrade process would fail on this is puzzling, but at least there’s a workaround. My home instance is running again, and I’ll have the work instance fixed on Monday (it’s currently on 17.11.2 IIRC).

Versions

18.0.0 CE

  • Self-managed
  • GitLab.com SaaS
  • Dedicated
System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   3.2.5
Gem Version:    3.6.7
Bundler Version:2.6.5
Rake Version:   13.0.6
Redis Version:  7.2.7
Sidekiq Version:7.3.9
Go Version:     unknown

GitLab information
Version:        18.0.0
Revision:       c481e1bd1b8
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     16.8
URL:            https://gitlab.alfter.us
HTTP Clone URL: https://gitlab.alfter.us/some-group/some-project.git
SSH Clone URL:  ssh://git@gitlab.alfter.us:222/some-group/some-project.git
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: 

GitLab Shell
Version:        14.41.0
Repository storages:
- default:      unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:      18.0.0
- default Git Version:  2.49.0.gl2