bug#7331: Date command bug
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#7331: Date command bug
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
bug#7331: Date command bug
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
