delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2010/12/19/16:14:26

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=BAYES_05,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
Message-Id: <E53F32EF-0D79-4541-B483-3405336B2FC1@free.fr>
From: Denis Excoffier <3 DOT 1416 AT free DOT fr>
To: cygwin AT cygwin DOT com
Reply-To: cygwin AT denis-excoffier DOT org
Subject: unexpected jumps to the future in the system date
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 19 Dec 2010 22:13:53 +0100
Cc: lasse DOT collin AT tukaani DOT org, cygwin AT denis-excoffier DOT org
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

Hello,

I've experienced a curious behaviour of /usr/bin/date, more especially  
some large jumps in the future.
Since i cannot formally exclude a BLODA problem, i'm not very  
comfortable at sending this, but
see the additional remarks at the end.

Program is `mytest':
---8<---------------------
#!/bin/sh

rm -f f1 f1.xz
echo "dummy text" > f1
# next line removes f1 and creates f1.xz (for those unfamiliar with  
`xz')
/usr/bin/xz -8 f1

/usr/sbin/zdump UTC
/usr/bin/date -u
/usr/bin/xz -d < f1.xz > /dev/null
/usr/bin/date -u
/usr/sbin/zdump UTC

rm -f f1 f1.xz
---8<----------------------

Result is (lines starting by # have been added by me afterwards):
---------------------------
Script started on Fri Dec 17 17:49:56 2010
jupiter% mytest
# time given by `zdump` is always correct
UTC  Fri Dec 17 16:50:00 2010 UTC
# time given by `date` is still correct here
Fri Dec 17 16:50:00 UTC 2010
#
# for `date`, there is a jump of 4.5 days!
#
Wed Dec 22 03:17:46 UTC 2010
# time given by `zdump` is always correct
UTC  Fri Dec 17 16:50:00 2010 UTC
jupiter% mytest
#
# 5 seconds later...
UTC  Fri Dec 17 16:50:05 2010 UTC
# `date` also is 5 seconds later
Wed Dec 22 03:17:51 UTC 2010
#
# now a jump of 6 seconds!
#
Wed Dec 22 03:17:57 UTC 2010
# in fact, less than 1 second has elapsed in reality
UTC  Fri Dec 17 16:50:05 2010 UTC
jupiter% mytest
#
# again 5 seconds later
UTC  Fri Dec 17 16:50:10 2010 UTC
# `date` also is 5 seconds later
Wed Dec 22 03:18:02 UTC 2010
#
# jump of 5 seconds!
#
Wed Dec 22 03:18:07 UTC 2010
# in fact, less than 1 second has elapsed in reality
UTC  Fri Dec 17 16:50:10 2010 UTC
jupiter% exit
exit

Script done on Fri Dec 17 17:50:11 2010
---------------------------

Remarks:
- i use XP, with McAfee perhaps not completely deactivated
- all versions are the last available in the mirrors:
   /usr/bin/xz, /usr/bin/zdump, /usr/bin/date, cygwin1.dll
- /usr/sbin/zdump is simply an alternate command to print the date
   it seems to remain functioning in the storm
- the -8 is an important detail: 32Mo will be needed to
   decompress the file; a similar option (eg -7 or -9) does not produce
   any weird behaviour
- i tried to replace the `xz -d' line with
   `dd bs=33M count=1 < /dev/zero > /dev/null' or similar but nothing
   special happened; also `xz -cd f1.xz > /dev/null' does not work
- this is 100% reproducible, only the jump amounts seems erratic


--
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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019