[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12772: date : Bug in handling human readable dates
From: |
Nemo Maelstrom Thorx |
Subject: |
bug#12772: date : Bug in handling human readable dates |
Date: |
Thu, 1 Nov 2012 12:07:47 +1000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#12772: date : Bug in handling human readable dates,
Nemo Maelstrom Thorx <=