| 10:51 | <Michael Ficarra> | anybody interested in picking up the date parsing proposal? https://twitter.com/domenic/status/1701888428244173166 |
| 10:51 | <Michael Ficarra> | this problem isn't going away on its own |
| 14:54 | <pipobscure> | I’d actually plead to leave the problem unresolved and simply declare Date as broken. |
| 14:54 | <pipobscure> | Temporal already solves the issue. |
| 14:55 | <pipobscure> | So the canonical solution should be to migrate away from Date to Temporal instead of patching and modifying existing Date behaviour |
| 14:55 | <pipobscure> | Especially as modifying the existing behaviour carries a risk of breaking the Web for anyone that has fixed this issue based on browser identification |
| 14:56 | <pipobscure> | (That’s of course just my highly biased 0.02€) |
| 14:57 | <ljharb> | also, it seems like a single project aiming to match another needing to reimplement another engine's date parser, one time, isn't much evidence of it being "needed" |
| 15:00 | <Michael Ficarra> | pipobscure: you aren't considering that engine implementors are one audience of the specification |
| 15:01 | <Michael Ficarra> | there's no way for a new engine to implement Date.parse in a web-compatible way from scratch via the spec |
| 15:01 | <pipobscure> | pipobscure: you aren't considering that engine implementors are one audience of the specification |
| 15:01 | <pipobscure> | I don’t understand what you mean. Could you explain? |
| 15:02 | <Michael Ficarra> | pipobscure: people writing new JS code are not the only ones who may be reading the spec to undstand how APIs are meant to behave |
| 15:02 | <pipobscure> | there's no way for a new engine to implement Date.parse in a web-compatible way from scratch via the spec |
| 15:02 | <pipobscure> | True that |
| 15:03 | <Michael Ficarra> | Web compatibility depends on particular behaviour of Data.parse that is not encoded in the spec. It is our job to address that. |
| 15:03 | <Michael Ficarra> | I don't see how that could be argued against |
| 15:04 | <pipobscure> | Is there precedence for “Let’s specify what new implementations should do while leaving all existing implementations alone.” ? |
| 15:04 | <Michael Ficarra> | yes, all the time |
| 15:04 | <Michael Ficarra> | and it's "precedent" |
| 15:06 | <ljharb> | unfortunately attempts to gradually specify that in the past have been blocked, and the requirement seems to be "specify everything all at once, or specify nothing", hence nothing's been done |
| 15:06 | <ljharb> | error stacks is in the same boat |
| 15:50 | <bakkot> | I’d actually plead to leave the problem unresolved and simply declare |
| 15:50 | <bakkot> | so I think it's still worth putting effort in, even for existing implementations, so we can avoid stuff like https://bugzilla.mozilla.org/show_bug.cgi?id=1825938 |
| 15:53 | <shu> | this is like, "we can't have justice, that's why we have the law", except it's "we can't tell people what to do, so we have standards that reflect reality" |
| 16:17 | <Michael Ficarra> | okay now that we all agree that clarifying Date.parse is, indeed, still valuable, does anybody want to take up this proposal again? |
| 16:22 | <Richard Gibson> | if the goal is "specify behavior of Date.parse that is required for web compatibility but not currently documented", I don't think https://github.com/tc39/proposal-uniform-interchange-date-parsing applies—it would be a brand new proposal |
| 16:23 | <bakkot> | This seems like it could be done somewhat incrementally: make a list of the cases where some implementation has needed to implement any particular behavior, and write that down |
| 16:24 | <bakkot> | and then say that things not in one of those forms are implementation-defined |
| 16:24 | <bakkot> | and then whenever a new one gets hit, add it to the list |
| 16:29 | <Richard Gibson> | in that case no proposal is necessary, just a sequence of web-reality PRs in (ecma262, test262) pairs |
| 16:37 | <Michael Ficarra> | Richard Gibson: Sure, a series of PRs would be fine, but I assume the research into what is commonly supported will mostly need to be front-loaded |
| 17:00 | <Richard Gibson> | to be frank, I don't see this going anywhere unless it's driven by current major implementations, who have pretty much no incentive. A fringe behavior is generally identified as required for web compatibility by observing breakage when it is changed, and some of those will be required in that sense even if they are not uniform across implementations. "Commonly supported" is a different concept but easier to determine, and if the committee establishes that as the criterion (basically encoding Hyrum's Law as a baseline) then what we'll end up with is an expansion of formats that must be accepted (and how to interpret them in ugly cases like "2023-02-30") and no description of what must—or even may—be rejected. Which is somewhat better than the current situation in which the same effectively holds but without documentation, although not by enough to motivate the kind of research you describe. but anyway, https://tc39.es/proposal-uniform-interchange-date-parsing/cases.html may be a decent starting point for any aspirational Don Quixote out there |
| 18:37 | <bakkot> | shu: did you see https://github.com/tc39/proposal-iterator-helpers/issues/286#issuecomment-1718129217 ? |
| 18:37 | <shu> | i did |
| 18:38 | <shu> | i can confirm the killswitch config is rolled out, but something else is wrong that it's not actually disabling the feature |
| 19:09 | <Rob Palmer> | The feature wants to live. |
| 19:10 | <Chris de Almeida> | life finds a way |