Re: [PATCH]: Fix for several getdate.y issues

[Jim Meyering]

Ondřej Vašík <address@hidden> wrote:
> Hello,
> while playing a bit with date formats, I found several issues (still
> present in GIT head). Current date on my machine is Fri Jun 27 11:58:47
> CEST 2008, used in all examples.
>
> 1) "Strange" results of signed relative time offset
> address@hidden ~]$ date -d "11:40 + 60 minutes"
> Fri Jun 27 12:41:00 CEST 2008
> address@hidden ~]$ date -d "11:40 + 61 minutes"
> Fri Jun 27 12:40:00 CEST 2008
> address@hidden ~]$ date -d "11:40 + 62 minutes"
> Fri Jun 27 12:39:00 CEST 2008
>
> 2) TZ shift ignored when relative time offset by days/months/years done
> (doesn't matter if signed or unsigned)
> address@hidden ~]$ date -d "11:40 UTC+0400 +24 hours"
> Sat Jun 28 09:40:00 CEST 2008
> address@hidden ~]$ date -d "11:40 UTC+0400 +1 day"
> Sat Jun 28 11:40:00 CEST 2008
>
> 3) numeric TZ is not limited by usual TZ limits UTC+14 and UTC-12
> (timezone used in example is UTC+5000000:00)
> address@hidden ~]$ date -d "11:40 +500000000"
> Fri Jul  2 07:33:04 CEST 1982
>
> 4) Date with dayshift could be quiet wrong
> address@hidden ~]$ date -d "11:40 UTC+0200 yesterday"
> Mon Dec 10 11:40:00 CET 2007
>
> 5) Multiplied dayshift is allowed as valid date
> address@hidden src]$ date -d "11:40 40 yesterday"
> Sun May 18 11:40:00 CEST 2008
>
> All of those issues are fixed by the getdate.y patch (and additional
> three test cases for date added in the second patch). Increase of
> potential shift/reduce conflicts in grammar is from 20 to 36, usually
> caused by some splits (tDAY_UNIT split to tDAY_UNIT, tWEEK_UNIT and
> tDAY_SHIFT). Some code duplicities in parser were replaced by functions.
> Input from example #3 and #5 now considered as invalid, others handled
> correctly by new grammar. This grammar past coreutils tests/misc/date
> without troubles. If you know about any situation where this new grammar
> will output invalid values, please let me know and I will try to fix it.
> TIA.

Hi Ondřej,

Good catches!
Thanks for working on this.

Would you mind separating that into a few separate change sets?
For example, a factorization-only change would be a good start.
No tests required for that.  However, that needs a few formatting changes:
- in a function definition, the function name must begin in col 1
- new pointer parameters must be const
- adjust type of new, time-related parameters.  at least one should be time_t

For coreutils, please add a NEWS entry for each bug fix.

I will have time next week to give this a more thorough review.