Hi Joe, thanks for the review!
There is indeed a chicken-and-egg problem here. I personally approached
this problem on behalf of the JavaScript standardization committee (ECMA
TC39) as part of our work on our new datetime API called Temporal
(https://tc39.es/proposal-temporal/docs/) but we've held up on shipping
this API until the format is standardized by IETF which has already
taken a lot longer than we originally predicted unfortunately and is
severely holding us back at this point. It seems like there's a mismatch
of expectations on various sides here. Part of the syntax we're
standardizing here is already implemented widely without standardization
which I felt was something folks weren't particularly happy about.
Your concern implies that there's an expectation for implementations to
accept the format before it's standardized but that seems to be
different from the mental model we've worked with so far. It's generally
much faster in my experience to actually push these updates in language
projects than it was to standardize it (although I acknowledge that
propagating these updates is a whole different challenge). So, should we
start pushing this format across the JavaScript and web ecosystems? I
can assure you that this format would become widely adopted once we do,
but we would lose any control over it at that point and therefore
decided to wait until the I-D is adopted as an RFC.
Cheers,
Ujjwal
On 12/06/2023 17:16, Joe Clarke via Datatracker wrote:
Reviewer: Joe Clarke
Review result: Has Issues
I have been tasked to review this document on behalf of the OPS DIR. Overall,
I struggled with this, and I don't know that "Has Issues" is the right result.
The document is well-written and clear (and let's face it, time is hard). But
as an operator, the backwards compatibility didn't resonate with me. I realize
there is a bit of chicken vs. egg here in terms of standardizing the new format
before tooling will use it, but I think this could cause some incompatibility
issues when you consider something like this:
```python
from datetime import datetime
datetime.fromisoformat("2022-07-08T00:14:07Z[!Europe/London]")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid isoformat string: '2022-07-08T00:14:07Z[!Europe/London]'
```
Until language libraries are updated for this, generators and consumers will be
out of sync. And let's face it: people don't always move to the latest version
of their favorite language or libraries.
So unless I'm missing something (and I might very well be), I think this
document would benefit from a section on migration guidance. Moreover, what
about some thought for some strptime/strftime format symbols for this to aim
for language consistency? I know this might not be the canonical place, but
given the Java references it seems like a recommendation might be acceptable.
On the smaller side, I think Section 5 should be baked into Section 3 to
introduce the u-ca notation before you use it in examples.
--
Ujjwal "Ryzokuken" Sharma (he/him)
Compilers Hacker at Igalia
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
