Discussion: Change ciso8601 "marketing"/"brand" to incorporate changes to the ecosystem?

[movermeyer]

When ciso8601 was first created, there were no reasonable alternatives to it. By virtue of being implemented in C, it was simply much faster than Python implementations.

However, time have moved on, and there are viable alternatives, so the choice is more nuanced.

For example, as of Python 3.7, there exists datetime.fromisoformat that provides the inverse of datetime.isoformat. While it is not a complete replacement for ciso8601 (ex. it doesn't support formats like YYYYMMDD), for users that were only ever using ciso8601 to provide that inverse, they might be better served by using fromisoformat.

Further, the Pendulum project has implemented a fast C parser as well. While pendulum will be slower, they support a wider subset of the ISO 8601 spec.

So there is now a spectrum of quality parsers that users might want to use:

datetime.isoformat               ciso8601                        pendulum

<----- Performance                                    Completeness ----->

It might be time for ciso8601 to change its marketing to be more nuanced. Originally, when there were no real alternatives, it made sense to say:

"We're the best, no questions. Use ciso8601."

But perhaps now we should be doing something similar to a flow-chart:

• If you only need support for Python 3.7, and just need an inverse to isoformat, use datetime.fromisoformat.
• If you only need to parse datetimes with the most common subset of ISO 8601, use ciso8601.
• If you need to parse datetimes with the entire ISO 8601 spec, use pendulum.

(Aside: I backported fromisoformat to pre-Python 3.7 versions: )

From a practical standpoint, this would involve mentioning alternatives in ciso8601's README (or perhaps a new document). It would also mean rewriting any other docs to tone down any rhetoric.

(Aside: In general, I'd like to see more collaboration between the various ISO 8601 parse projects, especially Pendulum and udatetime)

[ExplodingCabbage]

FWIW, I respect the attempt to clearly document when people should and shouldn't use your library.

If #70 gets merged, you'll have another reason to use this: strict parsing of RFC 3339. The standard library still doesn't support this in 3.7.

[movermeyer]

Closing this. I've documented the reasons not to use ciso8601 in https://github.com/closeio/ciso8601/blob/master/why_ciso8601.md (with snazzy Mermaid flow chart).

Aside: Once #140 is merged, the decision tree gets very simple 😁