It's all about the integers

As previously discussed in Floating point madness, the handling of fractional year, month, day, week, hour, and minute components of ISO 8601 dates and times is fraught with all kinds of peril. At the time, I chose a solution that was pretty immediately obvious, could be implemented quickly, solved a real problem with degenerate cases, and seemed intuitive. Even at the time, I mentioned it would only work for most cases, not all. Unfortunately, issue 24 highlights that working for most cases isn't good enough. Is there a solution that can work for all cases?

Floating point madness

In the course of squaring away sub-microsecond precision in aniso8601, the discussion came up that fractional components in general are rounded instead of truncated at maximum representable precision which can lead to the same kinds of problems pointed out in issue 10. At the time I pushed back because I figured it would lead to 'floating point madness' trying to get the correct behavior in all cases. Recently I was convinced to capitulate as I ran into a series of issues in my own use. Issue 21 covers this in some detail, but for those that want a complete breakdown, read on.

aniso8601 and sub-microsecond precision

After more false starts than I can count, aniso8601 is finally ready to handle sub-microsecond precision. Anyone following the (now approaching 3 year old) issue #10 will know that a solution wasn't immediately obvious. However, after fairly constant requests for "I want to parse an ISO 8601 timestamp and receive an X" and "why do you only support parsing to X and Y, I need to the parse result to be a Z" I came to the realization what people really wanted was a parser that just parses and to be able to build those parse results into whatever fits their use case best. Enter the 'builder' kwarg.

TLDR: New optional 'builder' keyword argument for all parse methods, 'relative' keyword argument going away. Default behavior is the same as always.

The great date parser race

Recently I've had a couple of conversations that made me wonder about Python parsers for ISO 8601. A topic I have a personal interest in.

The first conversation was about how a library providing some fundamental functionality turned out to be a bottleneck in a much larger program.

The second was about how slow regular expressions seem to be on ARM systems.

Parsing dates is a pretty fundamental function, and my date parser runs on ARM (and some of its competition (pyiso8601) uses regular expressions), so let's race!

aniso8601, now parsing 100% more durations with commas

My ISO8601 parser for Python (aniso8601) just hit version 0.83. As requested, I've added support for parsing durations where the decimal fraction is specified with a comma.

If you are one of those people that's into such things, the new version is up on PyPI. I don't handle the packages for various distros, so I can't help with those...