GNU bug report logs - #12318
gnu date has incorrect date when using date math during a leap year

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12318 in the body.
You can then email your comments to 12318 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Mizell <john.mizell <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: gnu date has incorrect date when using date math during a leap year
Date: Fri, 31 Aug 2012 08:39:12 -0600

gnu date has incorrect date when using date math during a leap year

Here are the steps to reproduce


[jmizell <at> backdoor ~]$ date "+%m%Y" --date='1 month ago'
072012
[jmizell <at> backdoor ~]$ date "+%m%Y" --date='5 month ago'
032012
[jmizell <at> backdoor ~]$ date "+%m%Y" --date='6 month ago'
032012
[jmizell <at> backdoor ~]$ date "+%m%Y" --date='7 month ago'
012012
[jmizell <at> backdoor ~]$ date "+%m%d%Y" --date='7 month ago'
01312012
[jmizell <at> backdoor ~]$ date "+%m%d%Y" --date='5 month ago'
03312012
[jmizell <at> backdoor ~]$ date "+%m%d%Y" --date='6 month ago'
03022012


Version:

[jmizell <at> backdoor ~]$ date --version
date (GNU coreutils) 8.4
Copyright (C) 2010 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.


Distro:
CentOS release 6.3 (Final)

Message #8 received at 12318 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: John Mizell <john.mizell <at> gmail.com>
Cc: 12318 <at> debbugs.gnu.org
Subject: Re: bug#12318: gnu date has incorrect date when using date math
	during a leap year
Date: Fri, 31 Aug 2012 11:59:52 -0600

John Mizell wrote:
> gnu date has incorrect date when using date math during a leap year

Thank you for the report.  But this appears to be incorrect usage.

> Here are the steps to reproduce

Thank you very much for providing your reproducing steps.  It makes
diagnosis easy.  So many people do not include enough information.

> [jmizell <at> backdoor ~]$ date "+%m%Y" --date='1 month ago'
> 072012

Two problems with the reproducer.  One is that you don't tell us what
timezone you are in.  Dates are very timezone dependent.  Secondly
+%m%Y does not give enough information.  I recommend -R, --rfc-2822
which will produce a standard and unambiguous result.

  $ TZ=US/Mountain date -R --date='1 month ago'
  Tue, 31 Jul 2012 11:30:38 -0600

> [jmizell <at> backdoor ~]$ date "+%m%Y" --date='5 month ago'
> 032012

  $ TZ=US/Mountain date -R --date='5 month ago'
  Sat, 31 Mar 2012 11:31:11 -0600

> [jmizell <at> backdoor ~]$ date "+%m%Y" --date='6 month ago'
> 032012

  $ TZ=US/Mountain date -R --date='6 month ago'
  Fri, 02 Mar 2012 10:31:34 -0700

I think at that you you can see where things have gone wrong.  The
date documentation warns of this case with this information:

     The fuzz in units can cause problems with relative items.  For
  example, `2003-07-31 -1 month' might evaluate to 2003-07-01, because
  2003-06-31 is an invalid date.  To determine the previous month more
  reliably, you can ask for the month before the 15th of the current
  month.  For example:

       $ date -R
       Thu, 31 Jul 2003 13:02:39 -0700
       $ date --date='-1 month' +'Last month was %B?'
       Last month was July?
       $ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B!'
       Last month was June!

Also the FAQ entry goes into some detail on this issue:

  http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

Months are problematic because subtracting 30 days (or even 31 days)
does not equate to a correct answer for everyone.  There is no
solution that everyone will agree is correct.  On March 1st
subtracting 30 days will yield a result of January.  As warned in the
documentation month calculations are better done at the time of the
middle of the month to avoid those issues.

At the least you should include a time of day so that the time that
math is being done isn't being done near a daylight savings time
change.

Taking that into consider and improving the usage yields:

  $ TZ=US/Mountain date -R --date='today 12:00z 6 month ago'
  Fri, 02 Mar 2012 05:00:00 -0700

  $ for i in 1 2 3 4 5 6 7 8; do date -R --date="2012-08-15 12:00 -0600 $i months ago";done
  Sun, 15 Jul 2012 12:00:00 -0600
  Fri, 15 Jun 2012 12:00:00 -0600
  Tue, 15 May 2012 12:00:00 -0600
  Sun, 15 Apr 2012 12:00:00 -0600
  Thu, 15 Mar 2012 12:00:00 -0600
  Wed, 15 Feb 2012 11:00:00 -0700
  Sun, 15 Jan 2012 11:00:00 -0700
  Thu, 15 Dec 2011 11:00:00 -0700

This way the month is correct.  We can see the effect of DST on the
result.  Doing all calculations in UTC avoids DST problems.

  $ for i in 1 2 3 4 5 6 7 8; do date -u -R --date="2012-08-15 12:00 +0000 $i months ago";done
  Sun, 15 Jul 2012 12:00:00 +0000
  Fri, 15 Jun 2012 12:00:00 +0000
  Tue, 15 May 2012 12:00:00 +0000
  Sun, 15 Apr 2012 12:00:00 +0000
  Thu, 15 Mar 2012 12:00:00 +0000
  Wed, 15 Feb 2012 12:00:00 +0000
  Sun, 15 Jan 2012 12:00:00 +0000
  Thu, 15 Dec 2011 12:00:00 +0000

Now if you are really looking to see what calendar date it would be
one month ago on the calendar then you need to supply an improved
definition of what one month means.  Is it four weeks with a week
being exactly seven days?  That can skip over months.  Is it 30 days
previously?  That can skip over months.  Is it the relative position
from the first of the month such as the first Monday?  Would
2012-07-31 minus one month be 2012-06-31?

There isn't any definition that makes sense in every case because
months are not consistent value items.  They vary in size.  For a
calculation such as this you would need to program in what you would
want with additional code that met your needs.

Hope this helps,
Bob

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: SciFi <sci-fi <at> hush.ai>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#12318: gnu date has incorrect date when using date math
	during a leap year
Date: Fri, 31 Aug 2012 18:40:10 +0000 (UTC)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

I am just a passerby here.  But when I see these specific
kinds of "errors", especially due to "month" usages, I always
have a thought:  How would we make GNU-date to operate on the
Month Number Itself when we type "month" in the --date string,
and stop its assumption that we mean "30 days" by this usage? 
We would not need to do this fooling-around with the Day-15
trick as shown.

I think this is where the "misusage" is being done by us
plain-ol' folk.  ;)

I hope I've expressed correctly what I mean with this thought.

(And I know: "Patches welcome." <g>)

Thanks for letting me interject my thought on this.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQQQP3AAoJEKkeWNKet7+KvpgH/RrOXg+DPYVvydJvWLPQy+Mr
7qcdBhtZhyqr++miO2s96231fbxy0r3T3QMMqmHqvzmJnmfkimNce0ax2AuKRh1s
RUS0mWzHE3qmdJQn8kataAdgK8tDjqawLCF9vxM4F4vjNyjBYSqDvLjr5zVYI1GV
uTBmwpRfPfi0GlsBd5sLW+HC1ipfkqr6zOEWT4R9XrvGNLcyKeWCX2ShKMLxGMiF
pgHJN+60mG18PpF/hF2GkPcnSpOWL2le+E9Jdw+UnzpIf5BkKN5DK3l4NHNKndW/
TeLqQoQvC+Aa4HxVK3VPLIS6egS4ttjP6By7WCisbxELbmaYD60SFMJrujZKRxo=
=/bjb
-----END PGP SIGNATURE-----

-- 

Message #20 received at 12318 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 12318 <at> debbugs.gnu.org
Cc: John Mizell <john.mizell <at> gmail.com>
Subject: Re: bug#12318: gnu date has incorrect date when using date math
	during a leap year
Date: Fri, 31 Aug 2012 14:22:33 -0600

SciFi wrote:
> I am just a passerby here.  But when I see these specific
> kinds of "errors", especially due to "month" usages, I always
> have a thought:  How would we make GNU-date to operate on the
> Month Number Itself when we type "month" in the --date string,
> and stop its assumption that we mean "30 days" by this usage? 
> We would not need to do this fooling-around with the Day-15
> trick as shown.

I understand the sentiment.  My personal one is that the "human"
language relative date code wasn't very well thought out and should
not have been released in the present form.  I also believe that
behavior change in long standing code is to be avoided since it breaks
so many things.  However this one is trouble to use correctly though
so I think changing it couldn't hurt too much.

> I think this is where the "misusage" is being done by us
> plain-ol' folk.  ;)

I think you are suggesting 2012-08-31 -1 month would end up with
2012-07-31, right?  Makes sense to me.  Hard to argue with it.  Right
up until 2012-08-31 -2 months comes along.  Is that 2012-06-31?  Or
2012-06-30 by force of will?  Or 2012-07-01 by math?  Or throw it as
an invalid date?  (Which I think would be less friendly.)  Or?  :-) 
It isn't a simple problem.

It would be great if there were some really smart artificially
intelligent program to process it.  It would have to smarter than a
human because even humans can't agree on this.

> I hope I've expressed correctly what I mean with this thought.
> (And I know: "Patches welcome." <g>)
> Thanks for letting me interject my thought on this.

I think it was a very good comment.

Bob

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: SciFi <sci-fi <at> hush.ai>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#12318: gnu date has incorrect date when using date math
	during a leap year
Date: Fri, 31 Aug 2012 22:06:50 +0000 (UTC)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi again,

Thank you for discussing this.

On further thought…

It seems that the "day" again is being "inserted" into this
situation, "ruining" the "proper answer".

I can see the automatic assumption of assigning "Day=Today" in
the present logic.  Again I would suggest a new option such as
- --no-assumptions or --pedantic to tell it *not* to make [such]
assumptions when that "piece" is not part of the "picture".

Let me explain:

The o.p. (Mr Mizell) shows several lines with only the month
and year to be presented.  No "day" at all.  The "A.I."
implied would be rather simple: it's begging to say "I don't
care about the Day, just deal with the Month [and Year] in
this equation."

By having just-this-much logic in GNU-date could perhaps
alleviate many of these type problems without breaking so-many
historical things while simultaneously providing "correct"
answers [hopefully finally].  Still without having to use the
Day-15 trick of course.  ;)

(…yeah, I still wouldn't know how to code this, alas…)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQQTRcAAoJEKkeWNKet7+K0d0H/0krWsNTmggUcDVtRrbGR6eg
h+7Czuo8O4oi+awujB8qj5VOVpXEc9aMlO83MuExgFchCgSeRMxkh9K9W2TIhSxZ
f43rhYpSoebGcz652vItmNCCSo0A24WSpqcVlZzCj1hWOJYXlMNVRPAIFmB2zvmh
JJ5Z1kSkHKuvuvqUhTz47K4oHSNnua1K8vLg98OK/F+FPEUzi0mfL7t743PCX9QT
PhZdkhAyl6pmcl3RJNDuK+Kt4HLshG2+W/YPisDlrlu8t0v1uuolwmDTeOMO6PuF
a/hUrlF8V2pGPqm/fYFQf02sxDawjZQqnBjLpOc10KdBp16kh73Nlq38mRExurU=
=jefA
-----END PGP SIGNATURE-----

-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.