Presumably this new API will fix the fact that JS does in fact know about some time zones, but not most.
Shield your eyes from this monstrosity that will successfully parse some dates using `new Date(<string>)` in some select special time zones, but assume UTC in the other cases:
It's more about the javascript spec. If the spec says "thou shalt support this and that" and one of the browsers implements more than that, we are now back in the 2000s where one browser may be supported by some websites but others aren't.
Canvas by Instructure, one of the largest LMS (learning management system) in the world officially supports all major browsers.
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.
I'm actually less surprised about this in 2024 than I would have been for a webapp in 2014.
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".
It was nice. As long as you weren't doing something totally inadvisable like using IE 7 or something, things generally worked fine. Blink, Gecko, WebKit, whatever. Even random tiny FOSS browser projects wrapping somewhat outdated builds of WebKit or Gecko worked ok the majority of the time as long as you spoofed the user agent string of one of the big guys.
People put serious effort into even IE compat for a while. AFAICT the beginning of the end came with trying to do battle with mobile browsers; you simply couldn’t debug all the potential problems well enough. I remember burning a month on a regression that affected only iOS before Apple fixed it. Of course people were going to eventually pick an easy standards based target and tell everyone else to pray.
After using Canvas for 2 years, I haven't had any problems with Firefox (except for the Lockdown Browser feature our school used to require, which I think is being gradually phased out).
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.
> 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.
> 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.
> 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.
"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
> Other multi-character (usually between 3 and 5) alphabetic time zones have been used in Internet messages. Any such time zone whose meaning is not known SHOULD be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning.
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)?
Honestly, it sounds like the most reasonable behavior here would be to _only_ support "Z" (optionally with "+<offset>") and none of the 3-letter codes. Unfortunately it would probably a breaking change to remove support for the existing codes, so it wouldn't happen.
Just to note, that table is from the "Obsolete Date and Time" section. AFAIK, RFC 2822 only really allows the number offsets and Z.
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.
Presumably this new API will fix the fact that JS does in fact know about some time zones, but not most.
Shield your eyes from this monstrosity that will successfully parse some dates using `new Date(<string>)` in some select special time zones, but assume UTC in the other cases:
https://github.com/v8/v8/blob/781c20568240a1e59edcf0cb5d713a...
This bit me hard in a previous role. :'(