Ondřej Vašík <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] ~]$ date -d "11:40 + 60 minutes" > Fri Jun 27 12:41:00 CEST 2008 > [EMAIL PROTECTED] ~]$ date -d "11:40 + 61 minutes" > Fri Jun 27 12:40:00 CEST 2008 > [EMAIL PROTECTED] ~]$ 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) > [EMAIL PROTECTED] ~]$ date -d "11:40 UTC+0400 +24 hours" > Sat Jun 28 09:40:00 CEST 2008 > [EMAIL PROTECTED] ~]$ 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) > [EMAIL PROTECTED] ~]$ date -d "11:40 +500000000" > Fri Jul 2 07:33:04 CEST 1982 > > 4) Date with dayshift could be quiet wrong > [EMAIL PROTECTED] ~]$ date -d "11:40 UTC+0200 yesterday" > Mon Dec 10 11:40:00 CET 2007 > > 5) Multiplied dayshift is allowed as valid date > [EMAIL PROTECTED] 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.
