Timezone reference for Weblate project deadlines and reminders

Short answer

Weblate stores project deadlines as timezone-aware UTC instants and evaluates them server-side; there is no per-project or project-owner timezone setting that moves the cutoff. In the releases I can speak to (the 4.x and 5.x series), an instant-level comparison happens against UTC. The one piece I cannot confirm from documentation alone is the day-granularity boundary ("due today" versus "overdue"), which depends on how the reminder task derives its date — see the verification steps below.

Confirmed behavior

• UTC storage. Weblate runs as a Django application with USE_TZ enabled in its default settings, so every DateTimeField — including the project deadline — is stored as an aware UTC value in the database.
• No project timezone field. Project administration exposes no IANA timezone identifier. The only timezone lever is the server-wide TIME_ZONE setting (or the container timezone in Docker deployments), which affects rendering defaults, not stored values.
• Display is client-side. The same deadline renders as different local dates for contributors in different regions. That is presentation only; the underlying cutoff does not vary per viewer.

What needs verification

With USE_TZ enabled, Django's timezone.now() returns a UTC-based aware datetime regardless of TIME_ZONE, so a direct comparison of deadline against now is UTC. The open question is whether the reminder logic derives "today" via timezone.localdate() or localtime() — if it does, the day boundary follows the server's TIME_ZONE instead, and a non-UTC server zone would shift "overdue" by hours. I cannot settle this from the documentation, so treat it as version-dependent until you check your installed source.

Three checks on your instance

1. Confirm the effective settings:

   weblate shell   # or: python manage.py shell
   >>> from django.conf import settings
   >>> settings.USE_TZ, settings.TIME_ZONE
   >>> from django.utils import timezone
   >>> timezone.now()

   You want True, 'UTC', and an ISO timestamp ending in +00:00.
2. Search the installed Python sources for deadline (grep -rn "deadline" --include="*.py" /path/to/weblate). Find the model field and the scheduled reminder task, and note whether the comparison uses timezone.now() (UTC) or localdate()/localtime() (server zone).
3. Run a behavioral test on staging: set a project deadline a few minutes ahead of the current UTC time and record when the reminder fires. If the day boundary matters to you, temporarily set a non-UTC TIME_ZONE on the staging copy and observe whether the trigger shifts.

Working with UTC deadlines day to day

• Treat the value you enter as a UTC instant. Announce deadlines with an explicit offset — "2026-11-02 23:59 UTC" — never as "end of day".
• If a team's local working day is the real target, convert once and enter the UTC equivalent: 23:59 CET (UTC+1 in winter) is 22:59 UTC.
• Do not change the server-wide TIME_ZONE to "fix" deadline timing. It shifts email timestamps, log entries, and any local-date logic together, trading one ambiguity for several.
• For per-project timezone semantics, nothing is documented in the versions I know. Check the current changelog or issue tracker for status rather than assuming a planned feature.

One detail that would sharpen this

Which Weblate version are you running, and is it the official Docker image or a native install? Docker images default to UTC unless you have overridden the container timezone, so the UTC-cutoff assumption is safe there. A native install with a customized TIME_ZONE is exactly the case where the source check in step 2 becomes necessary.