Before I continue responding, I’ll explain the terminology that I am used to:
* Backward compatibility = old data, new system.
* Forward compatibility = new data, old system.
Clearly, IXDTF is backward compatible with RFC 3339 (as adjusted by accepting the now common semantic interpretation of Z).
I think you are interested in what I’d call forward compatibility.
[JMC] Fair. If I have a new library, I expect it to understand old data (backwards). And while input validation is non-optional, I might end up throwing away a perfectly valid datetime if the thing handing me that data has awareness
of this new standard.
But there is generally (*) no way to add a receptacle for information to an existing format that did not have an extension point for that, so we didn’t try.
[JMC] Agreed. Which is why I suggested some guidance for those that might produce such a format during the transitional time to be aware of interop issues with existing libraries.
> 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.
I’m sensing an underlying assumption that IXDTF will replace plain RFC 3339 format for all applications. That was not the intention. (But of course we’d like RFC 3339 implementors to provide a mode where they are at least robust to additional information
in IXDTF format.)
[JMC] Given that this updates 3339, I did assume the [motherhood and apple pie] scenario that people embrace this additional metadata, yes.
> So unless I'm missing something (and I might very well be), I think this
> document would benefit from a section on migration guidance.
This, again, assumes there will be a massive, uncontrolled migration.
Instead, it seems the specifications that use RFC 3339 now should make deliberate decisions whether and how to deal with IXDTF additional information.
Many won’t need them (e.g., a future RFC 6991 ter would not migrate, but simply define new types so module authors could easily use IXDTF where that actually makes sense).
In others, they would drop right in, but still probably need some text how to make use of the additional information in the context of the specific specification.
[JMC] That text is what I’m requesting. One more scenario (again in Python):
>>> datetime.strptime("2022-07-08T02:14:07+02:00[Europe/Paris]", "%Y-%m-%dT%H:%M:%S%z")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
/opt/homebrew/Cellar/python@3.11/3.11.4/Frameworks/Python.framework/Versions/3.11/lib/python3.11/_strptime.py, line 568, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
/opt/homebrew/Cellar/python@3.11/3.11.4/Frameworks/Python.framework/Versions/3.11/lib/python3.11/_strptime.py, line 352, in _strptime
raise ValueError("unconverted data remains: %s" %
ValueError: unconverted data remains: [Europe/Paris]
[JMC] I’d just like it to be clear that if I produce this new format I may end up breaking users that try and parse it with existing libraries that are not yet aware.
> 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.
That looks harder to me than it might seem on first look — IXDTF is a vessel that can carry very different types of information, which would in turn need different kinds of representation in strp/ftime.
If we had strong structure on the strp/ftime curation side with whom we could develop a common proposal, maybe. But if we had that, we could rely on that specification to pick up some IXDTF functionality.
So I don’t think we want to load down the IXDTF format spec itself with API considerations for various platforms.
(But I wouldn’t mind setting up a Wiki pointing to existing and emerging implementations and their APIs!)
[JMC] Love the implementations idea! I was going to suggest an Appendix of known implementations, too. I realize this is perhaps outside the scope, but as an operator this kind of guidance and additional information go along
way.
And thank you for this editorial comment:
> 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.
To maintain the structure, I must admit I’d rather live with a forward reference here.
[JMC] Okay. Not a hill to die on and still I found the doc easy to read.
Joe
