Question
Safari Date Parsing Limits: Which String Formats Are Safe for Regional Time Zone Conversion?
Nia Vale
0 reputation · 03 Feb 2024, 16:36 UTC
48.2K views
Loading…
0 reputation · 03 Feb 2024, 16:36 UTC
I am building a web app that receives date-time strings from a backend and must display them converted to each user's regional time zone. The app needs to work reliably in Safari as well as Chrome and Firefox.
My understanding is that Safari's Date parser is stricter than other engines. Strings like 2024-01-15 10:30:00 (space separator instead of the ISO T) reportedly produce Invalid Date in Safari while parsing fine elsewhere, and date-only strings like 2024-01-15 are treated as UTC midnight, which can shift the displayed calendar day for users in negative-offset time zones. I would rather not depend on behavior that varies by Safari version.
The alternatives I am weighing are: normalizing all strings to full ISO 8601 with an explicit offset before parsing, constructing dates with the numeric new Date(year, monthIndex, day) form, or formatting via Intl.DateTimeFormat with an explicit timeZone option. I am also unsure whether the Temporal proposal is stable enough in current Safari releases to rely on.
Which input string formats are guaranteed to parse consistently across Safari versions? Is a numeric constructor plus Intl.DateTimeFormat sufficient for correct regional conversion, or is a parsing library still advisable? What is the current support status of Temporal in shipping Safari?
The only string formats that Safari parses consistently across versions are ISO 8601 strings that include an explicit time‑zone offset or the UTC designator "Z". Examples:
safari2025-08-27T14:30:00Z2025-08-27T14:30:00+02:002025-08-27T14:30:00-05:00Any other format (e.g., 2024-01-15, 2024/01/15, MM/DD/YYYY, or RFC 2822 strings) falls back to legacy, implementation‑specific parsing that varies with locale and Safari release, which can produce Invalid Date or unexpected regional shifts.
Safari’s Date constructor follows the ECMAScript specification: it attempts to parse ISO 8601‑like strings. When the string does not match that pattern, the engine falls back to a legacy parser whose behavior is not standardized and differs between Safari versions and the page’s locale.
const date = new Date(isoString);Intl.DateTimeFormat with the desired timeZone option:const formatted = new Date(date).toLocaleString('en-US', { timeZone: 'America/New_York', year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit' });Alternatively, avoid string parsing altogether by constructing the date from numeric components supplied by the backend:
const date = new Date(year, monthIndex, day, hour, minute, second, millisecond);Then apply the same
Intl.DateTimeFormatstep for display.Temporal support in Safari
As of Safari 17 (stable release, September 2023) the Temporal proposal is not enabled by default. It is available only behind an experimental flag in Safari Technology Preview. Therefore you cannot rely on Temporal for production‑wide Safari support at this time.
Use comments to ask for clarification. Post a solution as an answer.
29,775 reputation · 03 Feb 2024, 23:31 UTC
When you pass an ISO‑8601 string that lacks a time‑zone designator (e.g., 2024-09-26T14:30:00) to new Date() or Date.parse(), Safari interprets it as local time, not UTC. This means the resulting Date object already incorporates the user's device offset, so later calling toLocaleString with a timeZone option will apply the conversion on top of that local value, potentially causing a double‑shift. To avoid this, either append Z to force UTC or use the numeric constructor new Date(year, monthIndex, day, hour, minute, second, millisecond) (or Date.UTC) which creates a UTC‑based date independent of the device locale.