FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 05-31-2010, 06:23 PM
Ron Johnson
 
Default date bug?

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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4C03FEA2.6050401@cox.net">http://lists.debian.org/4C03FEA2.6050401@cox.net
 
Old 06-01-2010, 06:41 PM
"Boyd Stephen Smith Jr."
 
Default date bug?

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/ \_/
 
Old 06-01-2010, 07:32 PM
Ron Johnson
 
Default date bug?

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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4C05604A.3080503@cox.net">http://lists.debian.org/4C05604A.3080503@cox.net
 
Old 06-01-2010, 08:05 PM
Rick Thomas
 
Default date bug?

On Jun 1, 2010, at 3:32 PM, Ron Johnson wrote:

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.


Given what we know of ancient Roman practices (and Babylonian before
them), it's safe to say that he very well might have suffered exactly
that fate... /-;


Enjoy!

Rick


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 540C48D2-4E91-4A10-8B5B-BEB78E733849@pobox.com">http://lists.debian.org/540C48D2-4E91-4A10-8B5B-BEB78E733849@pobox.com
 
Old 06-01-2010, 08:22 PM
Tom Furie
 
Default date bug?

On Tue, Jun 01, 2010 at 02:32:26PM -0500, Ron Johnson wrote:
> 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.

But, it isn't even 52 weeks. It's 52 weeks + 1 day, except in a leap
year, when it's 52 weeks + 2 days.

We need a new calendar system where 1 orbit of the sun really is 1 year,
rather than 1 year + ~6 hours. Or ignore the sun for calendrical systems
and switch to a lunar system. I suppose we could just make an hour about
0.000683 times longer.

Cheers,
Tom

--
Distance doesn't make you any smaller, but it does make you part of a
larger picture.
 
Old 06-01-2010, 08:30 PM
"Boyd Stephen Smith Jr."
 
Default date bug?

On Tuesday 01 June 2010 14:32:26 Ron Johnson wrote:
> On 06/01/2010 01:41 PM, Boyd Stephen Smith Jr. wrote:
> > (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.

I think it was a collective work and that most of the key figures are long
since dead.

I'm open to suggestions on changing it, but there seems to be quite a bit of
momentum behind the current system. In addition, we are already working with
an astronomical clock that's not synced. (Really? 365.2425 days per year --
what exactly are the prime factors of that again?)

I vote for 25 hour days that start as soon as the midpoint of Sol crosses the
"ideal" horizon. The duration of a second might need to change. Ideally the
number of seconds per hour would remain a square number; it's root would
remain the number of seconds per minute and minutes per hour.

I vote for months that start on the first day after a "new moon". They'll
have 28-29 days, so we'll have about 13 of them a year, but New Year's Day
will drift a bit. (Why should January have all the fun, anyway?)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 06-01-2010, 11:03 PM
John Hasler
 
Default date bug?

Tom Furie writes:
> We need a new calendar system...

This _has_ been discussed:
<http://en.wikipedia.org/wiki/Calendar#Calendar_reform>
--
John Hasler


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aarecq51.fsf@thumper.dhh.gt.org">http://lists.debian.org/87aarecq51.fsf@thumper.dhh.gt.org
 

Thread Tools




All times are GMT. The time now is 07:13 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org