GNU bug report logs -
#7331
Date command bug
Previous Next
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.
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):
[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):
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):
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.