Hello, On Wed, May 22, 2019 at 10:41:52AM -0400, Michael Stone wrote: > In general my advice is to just avoid the date parsing entirely, it will > never, ever do what you predict.
I'm sorry to hear that is your experience with date(1) parsing. My different advice is to use "date --debug" to first troubleshoot what is being parsed, then search the mailing list archives for many common solutions, and lastly, write to [email protected] with questions. > If you find something that happens to work, > just copy and paste it and never change it. It would be nice if there were a > new, simple and predictable grammer option in date(1) (abandon the natural > language guessing) but nobody has ever wanted to do the work. :) The grammar is predictable (though perhaps not trivial) for the simple reason it is based on a fixed set of rules defined in a GNU Bison ".y" file: https://git.sv.gnu.org/cgit/gnulib.git/tree/lib/parse-datetime.y . There are no "natural language guessing" algorithms. Instead, and perhap that's the confusing part, there are many attempts by the parser to match date strings into known meaning. For example, NNNN/NN/NN is parsed as YYYY/MM/DD. NN/NN/NNNN is parsed as MM/DD/YYYY (the north american way). NNNNNN is parsed as YYMMDD (with YY being 19YY or 20YY with 69 as the cutoff). Then similar pattern are matched for time, timezone, and date/time adjustments. The different formats and patterns are explained here: https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html#Date-input-formats > You might try "2018-05-01 59 months ago", but I'd suggest using a python > module or somesuch with a more regular grammar if you want something > maintainable in the long term. I would argue that "long term" and "maintainable" is exactly what GNU date(1) parsing is. You'd be hard-pressed to find programs with longer-term support than gnu date(1), including python modules. The confusing and possibly frustrating part happens when trying to mix different parsing "parts" like date and time and timezone and relative time calculations. The "--debug" option should be the first tool to use. The most common issues are: Crossing daylight-saving-time (getting unexpected "tomorrow" results): https://lists.gnu.org/archive/html/bug-coreutils/2019-04/msg00003.html https://lists.gnu.org/archive/html/bug-coreutils/2016-04/msg00046.html https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30795 Mixing time and time-zones: https://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00126.html Months-related adjustments: https://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00357.html General adjustments, and order of operations: https://lists.gnu.org/archive/html/bug-coreutils/2018-02/msg00005.html Leap years and such: https://lists.gnu.org/archive/html/bug-coreutils/2017-03/msg00047.html Inner-working of date adjustments: https://lists.gnu.org/archive/html/bug-coreutils/2017-03/msg00044.html Hope this helps, -assaf
