/bin/date --date='next month' is wrong

[Mike Bianchi]

  cat i
/bin/date

/bin/date +'%B'
/bin/date --date='last month' +'%B'
/bin/date --date='this month' +'%B'
/bin/date --date='next month' +'%B'

  sh iSun Jan 30 16:59:31 EST 2011
January
December
January
March

Note that 'this month' == January and 'next month' == March

Looks like a bug to me ;)

Mike Bianchi

More info ...

  uname -a
Linux foveal4 2.6.24-28-generic #1 SMP Wed Nov 24 09:30:14 UTC 2010 i686 GNU/Linux

  date --version
date (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

  env
MANPATH=/usr/man:/usr/share/man:/usr/local/man:/usr/local/share/man
CVSROOT=/home/mbianchi/src/cvs
XDG_SESSION_COOKIE=fc5be364da5fcba6be068700465b3fb0-1296424178.733295-249958869
BROWSER=mozilla
LD_LIBRARY_PATH=/lib:/usr/lib
XDM_MANAGED=/var/run/xdmctl/xdmctl-:0,maysd,mayfn,sched,rsvd,method=classic
HOME=/home/mbianchi
DISPLAY=:0.0
MAILCHECK=0
SSH_AUTH_SOCK=/tmp/ssh-WaRbE10988/agent.10988
PWD=/usr/share/locale
PRINTER=ps
METAMAIL_PAGER=less -r -isX
WINDOWID=41943047
CVS_RSH=ssh
PS2=
SHLVL=0
DM_CONTROL=/var/run/xdmctl
RUBYLIB=/home/mbianchi/src/autoaud/lib/ruby
GS_LIB=/home/mbianchi/.fonts

[Josh Kupershmidt (schmiddy)]

It does seem counterintuitive, but this behavior appears to be by-design. See here for a similar issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301972

Feb. 30th is an invalid date which `date` doesn't want to return, which is why it's bumping the result into March.

[C de-Avillez (hggdh2)]

Thank you for opening this bug and helping make Ubuntu better. I am marking this bug WONTFIX -- recent coreutils has _improved_ on the fuzzy calendar calculations. Please note that calculations are still quite fuzzy, and this type of usage may get in some weird results.

@Josh: thank you for the Debian link.

[Mike Bianchi (mbianchi-foveal)]

On Mon, Jan 31, 2011 at 04:52:18AM -0000, Josh Kupershmidt wrote:
> :
> Feb. 30th is an invalid date which `date` doesn't want to return, which
> is why it's bumping the result into March.

This explanation does not quite square with the behavior. Witness:

          date
        Mon Jan 31 08:51:30 EST 2011

          date --date='this month' +%j
        031

          date --date='next month' +%j
        062

          date --date='next month'
        Thu Mar 3 08:57:01 EST 2011

So it _appears_ that the algorithm is
        next month -> +1 month
        month -> this month's number of days
        this month's number of days -> 31

        Julian date += 31

I find it hard to accept that the given behavior is "correct" even if it is
"as documented".

So now the question becomes "am I motivated enough to dig into the code,
understand it thoroughly enough to see what _is_ going on, and then do
something about it."

The simplest correct solution would seem to be:

 manipulations of "month" must take place as manipulations of
 the month field as expressed by the date format %m .

 _if_ the result is an illegal date ( i.e. 31 February )
 _and_ the day of month ( %d ) or julian day ( %j ) will be output,
 _then_
                output an illegal date error
    date --date='next month'
  date: invalid date `31 February'
 _else_
                output
                  date --date='next month' +%B
  February

Would that be deemed acceptable behavior by the keepers of /bin/date ?

[C de-Avillez (hggdh2)]

I can forward your comments to them (at <email address hidden> -- the generic comments/development list --, or at <email address hidden> specifically for bugs), or you can do it yourself. Note that I cannot copy you if I do it -- I do not have your email address; you can email me directly with hggdh2 at ubuntu dot com if you wish that I forward it.

A search on the coreutils mailing list shows many hits on this. For example, http://lists.gnu.org/archive/html/bug-coreutils/2007-01/msg00243.html states:

"This is the correct database, but it is not a bug, just an artifact of the
screwy way that humans track time. The GNU date documentation is explicit
that -1 month operates only on the month field without regards to how many
days are in a month, so '31 July -1 month' = '31 June'. But June does not
have 31 days, we have to guess whether June 30 or July 1 was intended. No
matter which way we guess, someone will complain we guessed wrong. So you
are stuck with the current behavior; if all you need is the month changed,
then calculate 'July -1 month' independently of the day (and consider a day
around the 15th of the month). A similar fuzzy boundary exists around
daylight savings boundaries."

There are many more hits. An interesting thread is at http://lists.gnu.org/archive/html/bug-coreutils/2010-08/msg00057.html. There is also the FAQ on date: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e.

Please tell me how you want to proceed.

Regards,