bug#15927: Bug in date command
date --date=10/20/2013 result in date: invalid date `10/20/2013' version: date (GNU coreutils) 8.13
bug#15927: Bug in date command
tag 15927 needinfo thanks On 11/19/2013 05:23 AM, Claudio Pinto wrote: > date --date=10/20/2013 > > result in > > date: invalid date `10/20/2013' We need more details, such as your current timezone. I suspect that you are running into a FAQ: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e in that you are probably in a timezone where daylight savings changed your time from midnight to 1am at the very start of that particular day, and therefore where there is no effective midnight on that date. But as I don't know what timezone you are in, I haven't managed to reproduce it locally (in my timezone, daylight savings changes occur at 2am rather than midnight). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#15927: Bug in date command
tag 15927 + moreinfo thanks Claudio Pinto wrote: > date --date=10/20/2013 > result in > date: invalid date `10/20/2013' In what timezone? You didn't give your timezone therefore it is impossible to know for sure but your problem statement matches one of the very common cases where Daylight Saving Time changes and therefore creates an invalid date in your timezone. Since you don't specify a time the time of 00:00 implicit. Better to work with raw dates around 12:00 noon which avoids all known timezone DST changes. Using the raw 'date' output gives ambiguous timezones. Better to use the standardized and unambiguous -R format. $ date -R --date=10/20/2013 Sun, 20 Oct 2013 00:00:00 -0600 $ date -R --date="10/20/2013 12:00" Sun, 20 Oct 2013 12:00:00 -0600 Even better is to always do date calculations in UTC to avoid any DST problems entirely. $ date -u -R --date=10/20/2013 Sun, 20 Oct 2013 00:00:00 + Please see the FAQ for a detailed discussion of date and DST. http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e Bob
bug#15927: Bug in date command
tag 15927 - moreinfo + notabug close 15927 thanks Hello Claudio, Please keep the bug log in the recipient list. That way others in the team on the mailing list can participate in the discussion. Claudio Pinto wrote: > Current default time zone: 'America/Sao_Paulo' > Local time is now: Ter Nov 19 17:10:40 BRST 2013. > Universal Time is now: Tue Nov 19 19:10:40 UTC 2013. > > Here in Brazil we have the time in an hour early. Yes. And that is the problem. The time you have specified does not exist. That is what makes it an invalid time. $ zdump -v America/Sao_Paulo | grep Oct.*2013 America/Sao_Paulo Sun Oct 20 02:59:59 2013 UTC = Sat Oct 19 23:59:59 2013 BRT isdst=0 gmtoff=-10800 America/Sao_Paulo Sun Oct 20 03:00:00 2013 UTC = Sun Oct 20 01:00:00 2013 BRST isdst=1 gmtoff=-7200 In the America/Sao_Paulo timezone as shown above the seconds of the clock tick to "Oct 19 23:59:59 2013 BRT" and the very next tick of the clock is "Sun Oct 20 01:00:00 2013 BRST". But you are asking for "Sun Oct 20 00:00:00" which does not exist in either BRT or BRST. Note that this is not a technology issue. This is an issue of changing the clock for Daylight Saving Time. Most countries do this by an act of government. > Removing a difference an hour, with the command below, the error does not > happen ... > date --date="10/20/2013 01:00" > with the command below error appears: > date --date="10/20/2013 00:59" Correct. Because those are invalid according to your America/Sao_Paulo timezone. To avoid those errors either use UTC which does not change for Daylight Saving Time or use 12:00 noon to avoid being near the time that it changes. Since this is a bug in usage and not a bug in the date calculations I am going to close the bug report. However if things are still not clear please feel free to follow up with any responses or comments and we can keep discussing it. Please keep the bug log address in the recipient list. Bob
