X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-3.4 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_HI,TW_HH,TW_JW,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
X-IronPortListener:	Outbound_SMTP
X-IronPort-Anti-Spam-Filtered:	true
X-IronPort-Anti-Spam-Result:	AgIBAN/Lz02cKEcW/2dsb2JhbACXUI5Fd65lmiOGGQSUXYpF
From:	"Buchbinder, Barry (NIH/NIAID) [E]" <BBuchbinder AT niaid DOT nih DOT gov>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>,
	"'Philippe'" <jwphubert AT gmail DOT com>
Date:	Sun, 15 May 2011 08:51:48 -0400
Subject:	RE: 1.5.25: bug in touch statement
Message-ID:	<0105D5C1E0353146B1B222348B0411A209E8030D16@NIHMLBX02.nih.gov>
References:	<415512198 DOT 1687271301267190457 DOT JavaMail DOT root AT zimbra6-e1 DOT priv DOT proxad DOT net> <277043603 DOT 1687291301267204451 DOT JavaMail DOT root AT zimbra6-e1 DOT priv DOT proxad DOT net> <871v1scd5c DOT fsf AT navakl084 DOT mitacad DOT com> <loom DOT 20110515T134854-740 AT post DOT gmane DOT org> <loom DOT 20110515T142237-268 AT post DOT gmane DOT org>
In-Reply-To:	<loom.20110515T142237-268@post.gmane.org>
MIME-Version:	1.0
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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 64=
bits
>> 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 forma=
t:
>>
>> 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, da=
y or
>> month.
>>
>> hh has another twist.  It will change time an hour MORE than what specif=
ied
>> 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, 00h=
55,
>> 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 =3D 1970-01-01 00:00:00 UTC.  This sch=
eme
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

- Raw text -