On Monday 31 May 2010 13:23:30 Ron Johnson wrote:
> On 05/31/2010 12:44 PM, Camaleón wrote:
> > On Mon, 31 May 2010 17:34:12 +0000, T o n g wrote:
> >> Please take a look at the following, do you think it is bug of date?
> >> $ date --date='next month'
> >> Thu Jul 1 11:07:31 EDT 2010
> >>
> >> I was hoping to get June.
> >
> > But June has not "31 days" so the closest is indeed "1st July" ;-)
> >
> >> Is it a bug, or there are other ways to get the correct answer?
> >
> > It's a "feature" when playing with relative time :-)
>
> When, on the last day of the current month, one enters the command
> "date --date='1 month ago'", one should see the last day of the
> previous month.
That's not entirely clear. I've worked with various systems and seen various
behaviors.
The main problem would be a program that does the following:
1. Take the current datetime, add 1 year then subtract 1 month and schedule an
event (called A) for that datetime.
2. Wait 8 hours.
3. Repeat (1), but call the new event "B".
4. Expect "B" to occur after "A".
Assume "05-31" - 1 month = "04-30": Then, if step 1 occurs on "05-30" and step
3 occurs on "05-31" then event B will occur before event A.
Assume, instead, "05-31" - 1 month = "05-01": Then, if step 1 occurs on
"05-31" and step 3 occurs on "06-01" then event B will occur before event A.
Assume, finally, "05-31" - 1 month = "04-31": Then, when will such an event
occur in real time?
> For example, in the RDBMS that I use at work:
> SQL> SELECT CURRENT_DATABASE, CURRENT_DATE - INTERVAL'1' MONTH
> cont> FROM RDB$DATABASE;
>
> 2010-05-31 2010-04-30
> 1 row selected
> SQL>
According to my reading of my draft of the SQL 200x standard, that behavior is
non-conforming. Section 6.30, General Rule 4 of the SQL/Foundation document
("-2") reads:
"In the following General Rules, arithmetic is performed so as to maintain the
integrity of the datetime data type that is the result of the <datetime term>
or <datetime value expression>. This may involve carry from or to the
immediately next more significant <primary datetime field>."
Section 6.30, General Rule 6b of the same document reads:
"If, after the preceding step, any <primary datetime field> of the result is
outside the permissible range of values for the field or the result is invalid
based on the natural rules for dates and times, then an exception condition is
raised: data exception — datetime field overflow."
I'd love to have someone confirm or dispute my reading based on the text of
the standard (or the publicly available draft). However, it seems a
conforming SQL system (RDBMS or not) should give you an error. (It may not be
entirely friendly, but any other behavior will be hard to reason about because
of inconsistencies.)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.