GNU bug report logs - #12772
date : Bug in handling human readable dates

Previous Next

Full log

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

From: Nemo Maelstrom Thorx <debianbug <at> nemo.house.cx>
To: 12772 <at> debbugs.gnu.org
Subject: Re: bug#12772: date : Bug in handling human readable dates
Date: Thu, 1 Nov 2012 12:07:47 +1000

Coincidentally, I found this bug just today also, and whilst
I acknowledge the workarounds if the only thing you need is the month,
sometimes you need the relative position within the month also.

I would suggest that the end of march's -1month would more intuitively
map to the end of february, repeated. ie, "lock" the month in, and
adjust the "least significant" part - the day. 

Same sort of unintuitive results can occur with requesting +1 month, or
even +/-1year from February 29. 


I also thought it might be illuminating to see how other systems handle
this ambiguity.

mysql> SELECT DATE_SUB('2012-03-31', INTERVAL 1 MONTH);
+------------------------------------------+
| DATE_SUB('2012-03-31', INTERVAL 1 MONTH) |
+------------------------------------------+
| 2012-02-29                               |
+------------------------------------------+
1 row in set (0.00 sec)

Colleagues inform me that postgresql behaves this way also, alongside
python's mx.DateTime library (and ms-sql too).

Conversely, sqlite, php behave like 'date' :)

.../Nemo

-- 
  ----------------------------------------- -----------------------------
                                                    earth native




-- 
  ----------------------------------------- -----------------------------
                                                    earth native

Previous Next

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