I only have time for a quick glance, but this catched my eye instantly:
april+1M returns 2021-05-02
Well, months are the worst beasts of all of date parts. This tool doesn’t seem to handle them if not well then at least intuitive. Adding a month to april cannot result in may 2 in a sensible way.
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
When you move down, a cursor selects “n” and then “t”. When you move back up, it selects “n” again and “e” again.
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.
I encountered this issue in the Google Keep application, which has a periodic reminder feature. I set a reminder for August 31, repeating monthly, but this results in it skipping months with 30 days as I discovered at the end of September.
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).
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.
Also plain old ActiveSupport. It doesn't have the natural language goodies, but it has all kinds of handily named methods, e.g. you can write (functional folks may want to look away)
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.
But the point of the standard isn't to provide something that everyone likes perfectly it's to provide a well defined format for exchanging datetimes instead of dealing with personal or cultural formats during interchange.
I don't think this is true, Italy uses generally slashes d/m/y or dashes d-m-y. France and Spain use slashes d/m/y. The Netherlands appear to use dashes: d-m-y. Hungary uses dots, but they use the y.m.d order. Sweden uses y-m-d.
My only grief with ISO8601 is that the way the timezones are denoted is somewhat unfortunate. Would have been nice if we could somehow have: 19:00+02:00 = 21:00+00:00 = 23:00-02:00, but alas.
I suppose I should also be annoyed that I somehow never manage to type dates in the correct format if I need to write them by hand, but I'm not sure if I can blame ISO for that.
The timezone sign convention is the same as the longitude sign convention: east is positive. The lat/long conventions are documented in ISO 6709, but they predate that standard, though I have not found a good history of it.
Note that these sign conventions are not universal: for example, POSIX has the reverse sign on timezone offsets because west positive was more convenient for american unix developers. There are similar oddities for longitude.
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.
When you move down, a cursor selects “n” and then “t”. When you move back up, it selects “n” again and “e” again.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.