Bug 578683 - date --date="last month" is off by one
Summary: date --date="last month" is off by one
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2373302 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-01 04:05 UTC by Dave Jones
Modified: 2025-06-23 08:30 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-04-01 08:11:51 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dave Jones 2010-04-01 04:05:02 UTC
(00:01:40:davej@gelk:Mail)$ date
Thu Apr  1 00:01:43 EDT 2010
(00:01:43:davej@gelk:Mail)$ date --date="last month"
Sun Feb 28 23:01:52 EST 2010


Confused by the TZ change ?

Comment 1 Ondrej Vasik 2010-04-01 08:11:51 UTC
Thanks for report. No, it's not confused, it works as expected, date just substracts one month from the date and then translates it into the new timestamp in format you want. Because of the daylightsaving change this month you have this one hour difference - but that's expected. See FAQ (http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e) for more details, closing NOTABUG.

Comment 2 Adam Jackson 2010-04-06 17:04:07 UTC
That's the dumbest thing I've ever heard.

Comment 3 Jeffrey C. Ollie 2010-04-06 17:41:17 UTC
The result may seem non-intuitive, but it's the way the math works out:

Start with "Thu Apr  1 00:01:43 EDT 2010" and convert to UTC:

$ TZ=UTC date --date="Thu Apr  1 00:01:43 EDT 2010"
Thu Apr  1 04:01:43 UTC 2010

Subtract one month (still in UTC):

$ TZ=UTC date --date="Thu Apr  1 04:01:43 UTC 2010 - 1 month" 
Mon Mar  1 04:01:43 UTC 2010

Then convert UTC to EST instead of EDT (since the DST switch happens in March):

$ TZ=EST date --date="Mon Mar  1 04:01:43 UTC 2010"
Sun Feb 28 23:01:43 EST 2010

Also, think of it this way - if the United States didn't observe daylight savings, "Thu Apr  1 00:01:43 EDT 2010" is actually "Wed Mar 31 23:01:43 EST 2010".

Comment 4 Adam Jackson 2010-04-06 18:29:30 UTC
It's the way the math works because it applies DST correction at a different place than a rational human would.  You can call that a feature if you like, but it's still intensely dumb.

Comment 5 Ondrej Vasik 2010-04-06 18:43:51 UTC
Yep, I see your point, there are many such "dumb troubles" (like invalid date in the case of 2:XX time in the day of DST correction change). It may look dumb, but the grammar of date is very complex(and obviously not perfect for everyone). But it is predictable (and it is possible to write scripts which will cover even those DST issues).

If you have any idea how to improve the grammar without regressions, feel free to propose it... but it is not so easy as it looks at first sight...

Comment 6 Dave Jones 2010-04-06 19:40:18 UTC
another example of spectacular failure.

$ export thismonth=$(date  "+%Y-3-30")
$ date -d "$thismonth 1 month ago" 
Tue Mar  2 00:00:00 EST 2010

the "1 month ago" feature seems so broken, it seems too dangerous to use.

Comment 7 Ondrej Vasik 2010-04-07 06:05:31 UTC
It's not failure - it's just what you requested ... not from human, but from computer. Let's be computer for a while: 
30th March - 1 Month => 30th February ... ah-there is no such ... so we are back in March and the answer is 2nd March.

Maybe some "human logic" option would be nice compromise, but I'm not sure if it will be acceptable by upstream (and easy to implement). Just to be sure - what's the answer of the comment #6 for you? February 27th? Ok - maybe, as it is one day before last day of previous month... and what about the same with March 2nd from human perspective? Will it be February 2nd? Yep, it seems so... but how to map 31 days of March on 28(usually) days of February? I still think that current "computer logic" is more predictable than "human one".

Comment 8 Lukáš Zaoral 2025-06-23 08:30:09 UTC
*** Bug 2373302 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.