Nova and Horizon: UTC Timestamp Translation Across Regional Time Zones
0 reputation · 25 Nov 2020, 05:25 UTC
0 reputation · 25 Nov 2020, 05:25 UTC
OpenStack services standardize on UTC for internal database storage and API timestamps to maintain consistency across distributed regions. However, the translation of these UTC timestamps into local user time zones often occurs at the client-side application layer rather than within the core API.
In multi-region deployments, the Nova compute service relies on the host OS clock for local event logging. If the Horizon dashboard is used to monitor instances across regions with differing system time zones, there is uncertainty regarding how the UI handles the conversion of the API's UTC output to the specific regional context of the instance.
This creates a potential discrepancy between the centralized API timestamp and the local host's event logs during audit trails.
28775 reputation · 25 Nov 2020, 10:42 UTC
1. Does Horizon let you switch between UTC and a Nova node’s regional time zone?
Profile → Time Zone or globally in horizon.conf.2. Is the conversion logic standardized or browser‑dependent?
TIME_ZONE and USE_TZ settings. When USE_TZ=True (the default), all datetime objects are timezone‑aware and converted to the user’s zone on the server before being sent to the browser.Intl.DateTimeFormat API performs the final formatting. If a browser lacks Intl support or JavaScript is disabled, Horizon falls back to displaying the raw UTC string./etc/openstack-dashboard/local_settings.py (or horizon.conf in newer releases). Verify:
TIME_ZONE = 'UTC'
USE_TZ = True
If you want a server‑side default other than UTC, set TIME_ZONE accordingly.sudo systemctl restart openstack-dashboard.service
python3 - <<'PY'
from django.utils import timezone
print(timezone.now().astimezone())
PY
The output should include the server’s local offset if TIME_ZONE is set.Profile → Time Zone, pick a zone (e.g., America/New_York), and confirm that timestamps on the dashboard shift accordingly.new Intl.DateTimeFormat('en-US', {timeZoneName:'short'}).format(new Date('2026-09-19T12:00:00Z'))
The result should reflect the selected user zone.timedatectl status.
/etc/localtime link pointing to the correct zone database? Verify with ls -l /etc/localtime.
X‑Forwarded‑Proto or X‑Forwarded‑For headers? That can affect JavaScript loading and time‑zone scripts.
USE_TZ was defaulted to False? Upgrade and re‑enable USE_TZ=True.
Once these items are confirmed, Horizon will correctly translate UTC timestamps to the chosen user time zone, and any discrepancy with Nova host logs will be due to the inherent difference between server and host clocks, not a Horizon bug.
Use comments to ask for clarification. Post a solution as an answer.
28,775 reputation · 25 Nov 2020, 10:21 UTC
While the OpenStack API returns raw UTC timestamps in ISO‑8601 (e.g., 2026-09-26T14:32:00Z), Horizon actually performs the conversion on the server side before the data hits the browser. Horizon’s Django view calls django.utils.timezone.localtime() using the TIME_ZONE and USE_TZ settings, then serialises the value as a string. The browser’s Intl.DateTimeFormat merely formats that string for display. Consequently, changing a user’s Horizon profile time zone only affects subsequent page renders; the current view must be refreshed to see the new offset. If you need the host’s local clock for audit logs, you’ll still have to consult the host’s system logs directly.