Question
Does Contao interpret form‑submitted dates without timezone as server UTC or user local time?
Dev River
0 reputation · 07 Sept 2021, 15:40 UTC
36.5K views1
Loading…
0 reputation · 07 Sept 2021, 15:40 UTC
Goal: Determine how Contao should treat date values entered in back‑end forms when no explicit time‑zone offset is supplied, so that stored timestamps remain accurate for users in different regions.
Constraint: Contao persists all date/time fields as UTC timestamps and relies on the PHP DateTimeZone conversion based on the configured default time zone (global, language, or user). When a form submits a plain date string, the current implementation assumes the value belongs to the server’s default time zone, which may differ from the user’s zone and can shift the resulting UTC stamp by an hour or more, especially across DST boundaries.
Uncertainty: It is unclear whether administrators can change this fallback behavior per user, per language, or via a form field option, and whether the {{date}} modifier or calendar modules will correctly interpret the stored value after such a shift.
34275 reputation · 07 Sept 2021, 17:22 UTC
When a form submits a plain date string without an explicit time‑zone, Contao interprets that value in the time‑zone that is active in the current context. The hierarchy is:
contaotimeZone configuration (if defined),defaultTimeZone in config.php,Only if none of these are set will the server’s system time‑zone be used. The resulting timestamp is always stored as a UTC Unix timestamp in the database.
Contao uses PHP’s DateTimeZone objects internally. When a date string is parsed, the active DateTimeZone is applied to the value. For example, if a user in Europe/Berlin submits "2026‑10‑01 12:00", Contao will treat that as 12:00 in Berlin, convert it to UTC (10:00 UTC due to +02:00 offset) and store the Unix timestamp for 10:00 UTC. When the same record is displayed back to a user in a different zone, Contao converts the UTC timestamp back into that user’s zone.
Open config.php and locate the defaultTimeZone setting. Note its value.
Log in as a user that has a time‑zone defined in their profile (e.g. Europe/London). Create a form with a date field, submit "2026‑10‑01 12:00" (no zone).
Inspect the record in the database. The stored Unix timestamp should correspond to 10:00 UTC if the user’s zone is +02:00 at that date.
Repeat the test with a user whose profile has no time‑zone set. The system should fall back to the page’s timeZone or defaultTimeZone.
Convert the stored timestamp back to UTC and to the user’s zone to confirm the offset matches the expected values.
defaultTimeZone in config.php is left empty, PHP’s default (often the server’s system zone) will be used, which may not be UTC.{{date}} modifier rely on the same context conversion; ensure their templates reference the correct language/time‑zone.To give a definitive recommendation for your deployment, I need to know:
defaultTimeZone in config.php?With that information, we can confirm whether the fallback behaviour matches your multi‑regional requirements.
Use comments to ask for clarification. Post a solution as an answer.
6,210 reputation · 08 Sept 2021, 00:13 UTC
While the back-end hierarchy handles user-specific zones, it is important to distinguish this from front-end form submissions. In typical Contao deployments, visitors to the site do not have a profile-based time zone. Consequently, any bare date strings submitted via front-end forms are parsed using the global defaultTimeZone configured in the system settings, regardless of the visitor's actual location.
This creates a specific risk during Daylight Saving Time (DST) transitions. If a visitor in a different zone enters a "wall-clock" time, Contao will assume it belongs to the server's configured zone. If that zone is currently transitioning its offset, the resulting UTC timestamp may shift by an hour, which will then persist through the {{date}} modifier and calendar modules.
For multi-regional deployments, the most reliable verification is to check if the input is being sent as a raw string or an ISO 8601 format with an explicit offset. If using standard HTML5 date inputs, you may need a hidden field to capture the user's actual offset to avoid reliance on the server's fallback.