Re: [Last-Call] Opsdir last call review of draft-ietf-sedate-datetime-extended-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux