Safari Date Parsing Limits: Which String Formats Are Safe for Regional Time Zone Conversion?
20.5K 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?