Hello folks. We got a bug on Ubuntu [1] where the OP (Mike, copied here) proposes a rework of the fuzzy 'date' calculations; I am copying his last comment here:
---- start comment ----
"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 ?"
---- end comment ----
Please note I closed the Ubuntu bug WONTFIX, since this is well
documented in both the info pages and on the FAQ.
Still, since Mike is willing to code, I considered it more
productive to contact you folks for a better analysis.
Please copy Mike on the replies, I am not sure he subscribes to the ML.
Cheers,
..C..
[1] https://bugs.launchpad.net/bugs/710368
signature.asc
Description: OpenPGP digital signature
