tag 702795 + moreinfo thanks Jose Manuel Abad Hernandez wrote: > When running "touch" to set the modification time of a file on Mars > 10, 2013, the application return <<invalid date format>> as shown > with the followings lines copied from the server console:
Thank you for your report. However what you are seeing is likely not a bug. It is likely due to the local timezone change. > root@pl:~#touch -m -t 201303100000.00 /var/tmp/borrame > touch: formato de fecha inválido «201303100000.00» > root@pl:~# What is your timezone? You did not say and it is needed to know if that time is valid in that timezone. From your domain name I will guess that the timezone is Cuba. Cuba changed to Daylight Saving Time at that moment. > Any other date in 2013 year runs fine. In the Cuba timezone that date is invalid. Along with other dates in the gap created when the clock was moved forward for DST. $ env LANG=C TZ=Cuba touch -m -t 201303100000.00 xx touch: invalid date format ‘201303100000.00’ $ env LANG=C TZ=Cuba touch -m -t 201303100059.00 xx touch: invalid date format '201303100059.00' It is much easier to use date to understand this: $ env LANG=C TZ=Cuba date -R -d '2013-03-10 00:00' date: invalid date '2013-03-10 00:00' But one second earlier is okay. $ env LANG=C TZ=Cuba date -R -d '2013-03-09 23:59' Sat, 09 Mar 2013 23:59:00 -0500 This is correct behavior. The reason is that Cuba changed to Daylight Savings Time at midnight. They moved one hour forward. That particular time does not exist. The timezone data can be printed for any timezone with the zdump command. Use it to show when DST went into effect in the Cuba timezone. $ zdump -v Cuba | grep 2013 Cuba Sun Mar 10 04:59:59 2013 UTC = Sat Mar 9 23:59:59 2013 CST isdst=0 gmtoff=-18000 Cuba Sun Mar 10 05:00:00 2013 UTC = Sun Mar 10 01:00:00 2013 CDT isdst=1 gmtoff=-14400 Cuba Sun Nov 3 04:59:59 2013 UTC = Sun Nov 3 00:59:59 2013 CDT isdst=1 gmtoff=-14400 Cuba Sun Nov 3 05:00:00 2013 UTC = Sun Nov 3 00:00:00 2013 CST isdst=0 gmtoff=-18000 The second before is "Sat Mar 9 23:59:59 2013 CST" and the very next second in that time is "Sun Mar 10 01:00:00 2013 CDT". There are no valid seconds in the timestamps between those two times. Therefore touch (and date) are behaving correctly. To avoid this problem it is best to work in UTC which never has a DST time gap. It also avoids the opposite problem when DST changes back. If local time is required then working with timestamps near noon instead of midnight should avoid DST problems. Please see the GNU Coreutils FAQ entry for date. It explains this issue in detail. It gives advice on how to avoid problems. http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e Bob
signature.asc
Description: Digital signature
