As we could see go and python have small differences, but it's OK.
One problem is that it (especially python's dateparser) does not report errors on invalid input, but almost always parse something. It has a `STRICT_PARSING` option, but it still allows invalid inputs (and cause different behavior on some relative dates), basically when the output contains numbers, the parser will return a date ...
One problem is that it (especially python's dateparser) does not report errors on invalid input, but almost always parse something. It has a `STRICT_PARSING` option, but it still allows invalid inputs (and BTW, this `STRICT_PARSING` seem to cause different behavior on some relative dates). With dateparser, basically when the output contains numbers, the parser will return a date ... that can be different from what user expected.
But with valid inputs, current implementations de-facto support so many formats, so for users who don't read the manual, it seem the tool support "any format and it will magically work", but sometimes it will not do what they think and cause bad surprises.
But with valid inputs, current implementations de-facto support many formats, so for users who don't read the manual, it seem the tool support "any format and it will magically work", but sometimes it will not do what they think.
The original need was to support using date in tidrange, without having to "calculate" the tid from hash.
Relative dates are a cool feature, but I feel the most common use cases would be to use absolute dates.
If we only supported only one simple format (ISO8601), we would be able to detect and refuse invalid inputs.
That said, this is a tool for power users, so maybe that's OK as is. All these arguments exists for any powerful but dangerous tools such as using chainsaw to cut wood faster or cars to move faster, maybe we should not worry here.
That said, this is a tool for power users, so maybe that's OK as is. All these arguments exists for any powerful but dangerous tools such as using chainsaw to cut wood faster or cars to move faster, so maybe we should not worry here.
While thinking about this, I checked unix `date` command and realized it also supports "clever" time parsing, for example:
