I only have time for a quick glance, but this catched my eye instantly:

  april+1M returns 2021-05-02

Some text editors have a similar feature for text lines. If you put your cursor at some column (including last one), then when moving up and down they try to retain that column if possible. E.g.

  short lin<cursor>e</cursor>
  longer line
  shrt

But if you place it at the end of line with ‘End’ key, it goes to the last char on every line when you move up/down. This is done by maintaining additional isAtEnd flag, until it is reset by a horizontal movement.

Month-to-day calculations should not add average (or now-related?) values to do a sensible thing. If you add month to a date (which for “april” I believe is “april 1”), it should just jump to “next-month 1”. If you add month to “march 31”, it should detect that it’s an end of month, and jump to “april 30” retaining isAtEnd until it’s reset by non-month operation, so +1M again gives “may 31”, and then -3M gives “feb 28(29)”. OR there should be a way to turn off “sticky end of month” mode. In no case that can result in “may 2”. Unless I’m missing something.

(I’ve made a similar library around ten years ago but never published it. It was designed for leasing contracts which love to use “a thursday before or including the fifth last day of a month next to the month in which insurance was paid” statements for their terms.

The most compact ISO-8601 format doesn’t use any separators within the date or time values, just to designate where the date field ends and where the time field begins, and that’s with an ASCII “T” character.

So long as you know what the other fields are and what their sizes are, you don’t really need separators.

Very interesting. I need to start collecting libraries that are capable of manipulating incomplete dates; twice I’ve had to implement that for work projects (Erlang and Python), but this and pdd look promising.

This seems like the kind of thing that could be implemented in Rust and then exported to (a) shared objects and (b) web assembly to be used by Python, Ruby, JS, Java, Go, &c, &c. The community would get so much more leverage out of fixes to this one library (consider the `april+1M` example) for probably the next twenty years (since it is unlikely that any of these platforms will be unamenable to all of (a) shared objects and (b) web assembly at any point in the forseeable future).

Reminds me of the Ruby library chronic https://github.com/mojombo/chronic

It's pretty good at natural language interpretation of dates, and the basic "from today" calculations, but cool to also see here natural expressions to parse between dates.

ISO(-8601) can go fly a kite. Dashes or forward slashes are confusable as subtraction and division respectively between numbers as year, month, and day separators. - and − do not have enough of a discernible difference to matter. Periods could work if not for the choice of using them to start file extensions. Commas are already used to group numbers in sets of 3 significant figures. Writing the year, month, and day as a sequence separated by commas is distinct as the month and day are at most 2 digits.