GNU bug report logs - #7331
Date command bug

Previous Next

Package: coreutils;

Reported by: Raymond Pete <raymond.pete <at> maine.edu>

Date: Thu, 4 Nov 2010 23:37:01 UTC

Severity: normal

Done: Bob Proulx <bob <at> proulx.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7331 in the body.
You can then email your comments to 7331 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7331; Package coreutils. (Thu, 04 Nov 2010 23:37:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raymond Pete <raymond.pete <at> maine.edu>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Thu, 04 Nov 2010 23:37:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Raymond Pete <raymond.pete <at> maine.edu>
To: bug-coreutils <at> gnu.org
Subject: Date command bug
Date: Thu, 4 Nov 2010 19:39:36 -0400
[Message part 1 (text/plain, inline)]
Hi,
I believe I have come across a small bug in the date command when daylight
savings time is in the process of being run.

Example:
    date --set "7 NOV 2010"
 -->Sun Nov  7 00:00:01 EDT 2010

    date --date="+1 day"
-->Sun Nov  7 23:00:40 EST 2010


It would appear in Eastern time zone case there is a small 2 hour window of
error here whereby the date command has set the zone before it is actually
supposed to be set. I have seen this with all time zone shifts. Noticed
first last weekend when BST went to GMT.

Could be a known bug.. if so, sorry to trouble you guys.

Best Regards,

Ray
[Message part 2 (text/html, inline)]

Information forwarded to owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7331; Package coreutils. (Fri, 05 Nov 2010 03:53:02 GMT) Full text and rfc822 format available.

Message #8 received at 7331 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Raymond Pete <raymond.pete <at> maine.edu>
Cc: 7331 <at> debbugs.gnu.org
Subject: Re: bug#7331: Date command bug
Date: Thu, 4 Nov 2010 21:56:34 -0600
Raymond Pete wrote:
> I believe I have come across a small bug in the date command when daylight
> savings time is in the process of being run.

Thank you for the report.  But what you are describing looks like
an incorrect expectation of behavior to me.

>     date --set "7 NOV 2010"
>  -->Sun Nov  7 00:00:01 EDT 2010

You don't need to actually set the date and mess with the system
clock.  Just use --date and have date interpret the date string.  It
would make for a more reliable example.

>     date --date="+1 day"
> -->Sun Nov  7 23:00:40 EST 2010

I assume that EDT and EST here are US/Eastern DST and US/Eastern
standard time?  Better to use 'date -R' to produce numeric values that
are not ambiguous.

  $ TZ=US/Eastern date -R -d "Sun, 07 Nov 2010 00:00:01 -0400 +1 day"
  Sun, 07 Nov 2010 23:00:01 -0500

> It would appear in Eastern time zone case there is a small 2 hour window of
> error here whereby the date command has set the zone before it is actually
> supposed to be set. I have seen this with all time zone shifts. Noticed
> first last weekend when BST went to GMT.

I don't understand.  "7 NOV 2010" doesn't have a time associated with
it and so the zero hour (midnight) is used.

  $ zdump -v US/Eastern | grep 2010
  US/Eastern  Sun Nov  7 05:59:59 2010 UTC = Sun Nov  7 01:59:59 2010 EDT isdst=1 gmtoff=-14400
  US/Eastern  Sun Nov  7 06:00:00 2010 UTC = Sun Nov  7 01:00:00 2010 EST isdst=0 gmtoff=-18000

November 7th at midnight is still within daylight savings time.  Then
you say "+1 day" which adds 24 hours to the current clock time and
produces a time that is 24 hours later but *after* US/Eastern has
changed to standard time.  "Spring forward and Fall back."  If you
were expecting it to be midnight on the next day then you have
forgotten that there is an extra hour inserted in the Fall when the
clocks are turned back one hour.

> Could be a known bug.. if so, sorry to trouble you guys.

I see no bug here.  Please explain if I missed something.

See also this reference for more information:

  http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

Bob




Reply sent to Bob Proulx <bob <at> proulx.com>:
You have taken responsibility. (Fri, 05 Nov 2010 20:57:02 GMT) Full text and rfc822 format available.

Notification sent to Raymond Pete <raymond.pete <at> maine.edu>:
bug acknowledged by developer. (Fri, 05 Nov 2010 20:57:02 GMT) Full text and rfc822 format available.

Message #13 received at 7331-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Raymond Pete <raymond.pete <at> maine.edu>
Cc: 7331-done <at> debbugs.gnu.org
Subject: Re: bug#7331: Date command bug
Date: Fri, 5 Nov 2010 15:00:47 -0600
Raymond Pete wrote:
> Thanks for the info Bob :-) I figured I missed something here.
> I see running my jobs just after midnight is probably not best.

I like running those types of calculations either at 12 noon or using
UTC.  Then the DST issues are avoided.

I also like using the 'date -R' format since it is RFC standard (used
in email and news) and unambiguous about timezones.  Otherwise I like
using "%F %T %z" for being compact, unambiguous, and sorts nicely.

I will go ahead and close the bug with this email then.

> Appreciate all the work you guys do!

The team enjoys hearing those nice words.  :-)

Bob




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 04 Dec 2010 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 14 years and 256 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.