Hey there! We've found the following might help you get unblocked faster:

• 🧵 Environment Variable Issue

• 🧵 Environment variable seems to be cached or not updating

• 🧵 How to run code in a node?

• 🧵 Django REST Framework on Railway: Environment Variables Not Being Recognized[solved]

If you find the answer from one of these, please let us know by solving the thread!

if youre using a docker file, you can just add:

ENV TZ=America/Mexico_City

RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

its likely the process didn't apply TZ at runtime because it isnt linked to /etc/localtime, so the OS stays on UTC

It is best to always keep timestamps in UTC and convert them to the localized timezone for display purposes.

I am using GitHub, so how to make this work on a Django/python project?

hey isaachm11, In Django, the TZ environment variable won’t change the behavior you’re seeing because Django ignores the system timezone whenever USE_TZ = True.

With your settings:

TIME_ZONE = 'America/Mexico_City'

USE_TZ = True

Django will always store and return datetimes in UTC internally. That’s why datetime.now() still shows UTC: it comes from Python’s standard library, not from Django’s timezone system. To get local (Mexico City) time in Django, use:

from django.utils import timezone

timezone.localtime() # This will reflect America/Mexico_City

This is the recommended approach. You don’t need to modify the system timezone or add Dockerfile/Procfile settings. Keeping the container in UTC and letting Django handle timezone conversion is best practice.

Here’s how to properly handle timezone configuration on Railway for a Python/Django app — and what’s happening in your case.

Root Cause

Railway containers are ephemeral and UTC-based by design.
The environment variable TZ is not automatically applied to the OS-level timezone in Railway’s runtime environment (unlike some Docker images that respect /etc/localtime or TZ at startup).

So while you may see TZ=America/Mexico_City set in the environment, Python’s runtime (and Django) will still use UTC unless explicitly told to load and use that timezone.

Recommended Solution (Django-native)

Since Django already manages timezones internally, you don’t need to rely on the system timezone.

In your settings.py, you already have:

LANGUAGE_CODE = 'es-mx'
TIME_ZONE = 'America/Mexico_City'
USE_I18N = True
USE_L10N = True
USE_TZ = True

With this configuration:

• All datetimes are stored in UTC in the DB (best practice).

• Django automatically converts to America/Mexico_City for display or templates if USE_TZ=True.

To check:

from django.utils import timezone
timezone.localtime(timezone.now())

→ should show America/Mexico_City offset (UTC-6 or UTC-5 depending on DST).

If you instead use datetime.now() (without timezone awareness), it will always show UTC, because it’s not Django-aware. Use timezone.now().

Optional: System-level TZ (if you truly need it)

If you have a background process (e.g., a cronjob, logging, or 3rd-party binary) that depends on local system time, you can force the container timezone manually:

Option 1: via Dockerfile

FROM python:3.11-slim
ENV TZ=America/Mexico_City
RUN apt-get update && apt-get install -y tzdata && \
    ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

Then redeploy your service on Railway with that Dockerfile.

Option 2: via Procfile command

If you’re not using a custom Dockerfile, prepend the TZ setting to your run command:

web: export TZ=America/Mexico_City && python manage.py runserver 0.0.0.0:$PORT

💡 Summary

GoalMethodRecommendedApp-level timezone (Django-aware)TIME_ZONE + USE_TZ=True Best practiceOS-level timezoneSet TZ + install tzdata in Dockerfile Only if necessaryQuick fix for command-line logsPrefix Procfile with export TZ=... Optional