date bug?
in [Debian]
|
From: T o n g on 31 May 2010 13:40 Hi, Please take a look at the following, do you think it is bug of date? $ date Mon May 31 13:26:13 EDT 2010 $ date --date='1 month ago' Sat May 1 13:24:20 EDT 2010 $ date --date='last month' Sat May 1 11:09:21 EDT 2010 $ date --date='-1 month' Sat May 1 13:26:49 EDT 2010 All above should give me some time in April, IMHO. (please disregard the time, I am copying/pasting from my execution history) Same problem with "next month": $ date --date='+1 month' Thu Jul 1 13:29:23 EDT 2010 $ date --date='next month' Thu Jul 1 11:07:31 EDT 2010 I was hoping to get June. Is it a bug, or there are other ways to get the correct answer? Thanks -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/hu0ruk$3l2$1(a)dough.gmane.org
From: Camaleón on 31 May 2010 13:50 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 :-) *** info date (Relative items in date strings) (...) When a relative item causes the resulting date to cross a boundary where the clocks were adjusted, typically for daylight saving time, the resulting date and time are adjusted accordingly. The fuzz in units can cause problems with relative items. For example, `2003-07-31 -1 month' might evaluate to 2003-07-01, because 2003-06-31 is an invalid date. To determine the previous month more reliably, you can ask for the month before the 15th of the current month. For example: *** Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/pan.2010.05.31.17.44.28(a)gmail.com
From: Ron Johnson on 31 May 2010 14:30 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 :-) > > *** > info date (Relative items in date strings) > > (...) > > When a relative item causes the resulting date to cross a boundary > where the clocks were adjusted, typically for daylight saving time, the > resulting date and time are adjusted accordingly. > > The fuzz in units can cause problems with relative items. For > example, `2003-07-31 -1 month' might evaluate to 2003-07-01, because > 2003-06-31 is an invalid date. To determine the previous month more > reliably, you can ask for the month before the 15th of the current > month. For example: > *** > 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. 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> -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4C03FEA2.6050401(a)cox.net
From: Boyd Stephen Smith Jr. on 1 Jun 2010 14:50 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(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
From: Ron Johnson on 1 Jun 2010 15:40 On 06/01/2010 01:41 PM, Boyd Stephen Smith Jr. wrote: [snip] > > 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.) That's why whomever came up with the complete idiocy of breaking up 52 weeks into 12 irregularly-sized months, days starting in the middle of the night and years in the middle of winter, should br brought behind the barn and flayed alive. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4C05604A.3080503(a)cox.net
|
Next
|
Last
Pages: 1 2 Prev: To find out the installed packages repo section. Next: How long squeez supported |