Sign in Subscribe

Sitecore Pages and Time Zones

Sitecore Pages and Time Zones
Photo by Jon Tyson / Unsplash

Recently I ran into some interesting usability challenges due to the current lack of support for local time zones in Sitecore Pages. I had two components to implement: one referenced a Sitecore date field and displayed a single date to the visitor (think of an article date), and the other used two datetime fields to display an event date range (e.g. "January 10-12, 2026"), or a time range if both dates were on the same day (e.g. "July 10, 7-9 PM EDT"). To support the time zone display, the specifications called for a time zone selector, where authors could select one of the major US time zones, "Eastern", "Central", "Mountain" or "Pacific".

Traditionally, the first component could be supported by a Sitecore date field, and the second by two datetime fields. Both field types store the value the user enters in UTC time, stored in ISO 8601 format ("yyyyMMddThhmmssZ"). But traditional Sitecore interfaces like Content Editor take the server time zone into account (optionally overridden by the "SeverTimeZone" config setting), so that if the server is on US Eastern Time, and a user selects July 17, 2025, the value stored will be 20250717T040000Z. This is helpful, because if the date is then converted from UTC to local time, it will continue to show the date the author selected.

Pages, on the other hand, will store 20250717T000000z, which will render as July 16 if converted to US Eastern time. In fact, the Pages display shows this will happen, but gives authors no way to correct this.

Pages date field, with helper text showing date in local time zone.

There's no good way around this usability issue with date fields. You can inform users to enter the next day (confusing), add a secondary time zone field and treat the UTC value as actually in that time zone (disregards Sitecore guidance to always use UTC when storing dates, and leads to data that is difficult to interpret), or you can ask users to go to Content Editor and append the 040000.

Given these bad options, we opted to avoid the date field type altogether, and require users to enter dates using a datetime field, and manually append the 040000. This keeps users in Pages, and the Datetime control displays "(UTC)" so there's no chance of ambiguity. But forcing authors to think about time zones to this degree does not provide a polished authoring experience.

Pages datetime field, with UTC displayed, and helper text in UTC.

How do I recommend that Pages handle this? There are several options. Pages could respect the "ServerTimeZone" configuration setting (I've requested this as feature request PGS-2262), or could make use of the JavaScript "getTimezoneOffset" to apply an offset to the date field. For backward compatibility, this could be enabled by environment variable or could be an option presented to the author in the date selector itself.

I lean to a JS-based approach enabled by an optional environment setting, as it avoids tying Pages to closely to Content Manager and would not be a breaking change. But some improvement is required in my view. The Date field is simply too confusing as it currently stands. And even with the datetime field, forcing authors to think in terms of UTC does not seem user friendly to me.

References