Server-wide TIME_ZONE vs client-side conversion for Weblate timestamps

Decision context

p>Weblate stores all timestamps in UTC and renders UI dates using the server-wide TIME_ZONE setting. There is no per-user time-zone field in the user profile, and only a few JavaScript components perform browser-local conversion for relative times.

Recommendation

To minimize maintenance overhead and ensure data integrity across the ecosystem, the recommended approach is to enforce a single server time zone (UTC) for all users. This ensures that logs, deadlines, and API responses remain consistent regardless of the translator's physical location.

Trade-offs

• Single server zone: Simple, consistent across logs, deadlines, and API responses; requires no template changes or custom server-side logic overrides.
• Per-user conversion: Matches each translator’s local time but requires custom middleware, template overrides, and significant maintenance overhead as Weblate updates.

Implementation and Verification

If you opt for the server-wide strategy, follow these steps to ensure consistency:

1. Ensure TIME_ZONE = 'UTC' is set in your Django settings.py.
2. Verify that all API responses return ISO-8601 strings with the 'Z' offset to prevent ambiguity for external consumers.
3. Use client-side JavaScript (like Intl.DateTimeFormat) only for specific UI components where local relative time is critical for user experience.

Assumptions and Uncertainty

This analysis assumes that your external API consumers are capable of handling UTC timestamps. If your integration layer relies on local-time strings without offset awareness, a server-side UTC strategy may break downstream systems. We are uncertain whether your specific workflow requires hard deadlines to be viewed in local project time, which might necessitate the per-user conversion logic.

Diagnostic Question: Does your project require hard deadlines to be displayed relative to the translator's local clock for synchronization purposes?