Joe Clarke (12 June 2023 17:16) wrote:
> 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.
Yup. Although, to be fair, your string isn't in ISO format, so that
function may take a while before it *should* accept it. But python may
well need some new methods, or to be an early adopter in the hope that
ISO basically follows this WG's work, once it gets there.
I maintain the Qt project's date and time code, so watch this list
precisely so that I know what to implement - when I can persuade
managers to prioritise [QTBUG-114172] enough to put it near the front of
my queue. Which will get easier once this standard is an official RFC.
[QTBUG-114172]: https://bugreports.qt.io/browse/QTBUG-114172
I can't speak for all implementors, but my guess is I'm not the only one
who needs this RFC to justify getting tooling to support it. We make
strong backwards-compatibility promises - and rushing into implementing
a new standard before it's official runs the risk of being later forced
to break those promises if the final version of the standard is
different. But I don't want to be too tardy, either.
> And let's face it: people don't always move to the latest version
> of their favorite language or libraries.
and some are stuck with the heaving old pile of junk they have to
continue supporting, for which the new versions never shall be
available.
> 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.
All good points. I'll add: the Unicode Consortium's Common Locale Data
Repository [CLDR] supplies date formats for locales, using format
strings defined as part of the Locale Data Mark-up Language (LDML) whose
list of date patterns [Date] does include entries for the zone, in
various forms. Liaising with them about how to represent sedate's zone
annotations, plus calendar annotations, might make some sense, although
it's not strictly relevant until some locale (typically a culture or its
officialdom) starts using them; but perhaps en_US@POSIX is the locale
that'll start that. Their list of zone formats may also be a good place
to start for suggestions for how to fit this into strptime/strftime's
format language.
[CLDR] https://cldr.unicode.org/
[Date] https://www.unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns
Eddy.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
