Philippe sent the following at Sunday, May 15, 2011 8:25 AM >Philippe <jwphubert <at> gmail.com> writes: >> I've found an interesting behaviour with this command on my Windows 7 64bits >> system. It seems that there is a bug, or that we should change the >> documentation... But I can get around with the following date/time format: >> >> MMddhhmmyy >> >> where >> >> MM: Month (01-12) >> dd: day (01-31) >> hh: hours (00-23) >> mm: minutes (00-59) >> yy: 2 digit year >> >> yy is interesting. 00 to 37 yields 2000 to 2037. 70 to 99 yields 1970 to >> 1999. 38 to 69 leaves the date unchanged, even for new correct time, day or >> month. >> >> hh has another twist. It will change time an hour MORE than what specified >> the command line. If you want the file date to be 9AM, you enter 08. >> twist, if you specify 1231235511, the file date will be 2012 dec 31, 00h55, >> hour later than the one specified. > >on Another an Sorry, little mistake. On my previous post, your should >read: > >"Another twist, if you specify 1231235511, the file date will be 2012 >jan 01, 00h55, an hour later than the one specified."
The yy works that way because the UNIX epoch. Time is measured in seconds and encoded as a 32 bit integer, where 0 = 1970-01-01 00:00:00 UTC. This scheme runs out of bits at 2038-01-19 03:14:07 UTC. See <http://en.wikipedia.org/wiki/Unix_time> and <http://en.wikipedia.org/wiki/Year_2038_problem> I don't know about the hours, but a one hour difference always suggests to me a problem due to summer time, though it might have something to do with time zones. Add to that how interaction with Windows and how it handles daylight savings time and time zones. Good luck, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
