It knows about 8 time zones in 4 different offsets, and that's it?
I ask because yes, everything on the site points that way. But it's still so hard to believe that some confirmation would be good.
Unofficially schools tell students to use Chrome because some tasks fail often outside of Chrome. In particular Safari's default settings for cookies/privacy often causes the system to fail - particularly with integrations that use iframes/popups and other antiquated tricks.
The year is 2024.
I feel like we peaked somewhere around the mid 2010s with regards to application compatibility: No more Flash, but also more than just 1.5 rendering engines.
Before that, it was all "oh, sorry, Windows .exe only"; since then, "sorry, Chrome visitors only".
I don't think this is correct. I think the JavaScript spec here defines a string format which is extremely narrow, but then leaves it open to browsers implementing whatever they want.
https://262.ecma-international.org/5.1/#sec-15.9.4.2
> The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
https://262.ecma-international.org/5.1/#sec-15.9.1.15
> ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
> Z is the time zone offset specified as “Z” (for UTC) or either “+” or “-” followed by a time expression HH:mm
> Note2: There exists no international standard that specifies abbreviations for civil time zones like CET, EST, etc. and sometimes the same abbreviation is even used for two very different time zones. For this reason, ISO 8601 and this format specifies numeric representations of date and time.
The hint as to what is going on then comes from MDN, which more documents the ground truth than the goal.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> There are many ways to format a date as a string. The JavaScript specification only specifies one format to be universally supported: the date time string format, a simplification of the ISO 8601 calendar date extended format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
> Note: You are encouraged to make sure your input conforms to the date time string format above for maximum compatibility, because support for other formats is not guaranteed. However, there are some formats that are supported in all major implementations — like RFC 2822 format — in which case their usage can be acceptable. Always conduct cross-browser tests to ensure your code works in all target browsers. A library can help if many different formats are to be accommodated.
That table then comes from RFC2822, which also doesn't want you to use string named time zones, but as RFC822 has such it needs to still support it a bit--I imagine this probably came from back when this was used by ARPA-- and so has a section on "obsolete" date and time format extensions, which only explicitly requires support for US time zones and (notably) military formats.
https://datatracker.ietf.org/doc/html/rfc2822#section-4.3
"UT" / "GMT" / ; Universal Time
; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7
%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case
So, a spec, sure, but not the JavaScript spec, and not because if Chrome supported something weird then JS would get mad (as JS nigh unto suggests going above and beyond), and even RFC2822 (itself already outside JS) leaves open the door for more zones... in practice, I actually think JavaScriptCore might support even more formats (but could be totally wrong on that)?
Anyway, yeah, that does explain the situation we are in. And yeah, it looks like if you are extremely literal-minded and insist on supporting obsolete notations on your new thing, that would make your code be exactly like the one the OP pointed.
It's a bad decision all around, because the RFC 2822 isn't concerned about general purpose time handling. A programing language shouldn't use something like this.
Somebody posted the spec as a reply, and looks like the standard can be read in a way that mandates exactly that.