X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.0 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,TW_DW
X-Spam-Check-By: sourceware.org
Message-ID: <4F1C73D6.10702@overbearing.org>
Date: Sun, 22 Jan 2012 21:38:46 +0100
From: cygwin <cygwin AT overbearing DOT org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: 1.7.9 : date command fails for year 1900
References: <4F1A07F6 DOT 8010509 AT overbearing DOT org> <0105D5C1E0353146B1B222348B0411A20A51C5679C AT NIHMLBX02 DOT nih DOT gov>
In-Reply-To: <0105D5C1E0353146B1B222348B0411A20A51C5679C@NIHMLBX02.nih.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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

Thanks for corroborating my finding.  Does anybody else think it is odd 
that this has not been pointed out before?  Why would date use signed 
long integers to hold numbers of seconds?  You would think this problem 
would have been detected in like 1974 or so.  Do I just suck it up, or 
is there a work around for this?  I am on 32bit winXP if it helps any.

Incidentally cal seems to figure out dates in the distant past just fine:

$ cal 14 10 1066
     October 1066
Su Mo Tu We Th Fr Sa
  1  2  3  4  5  6  7
  8  9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31



Regards,
-Dave


On 1/22/2012 7:21 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> cygwin sent the following at Friday, January 20, 2012 7:34 PM
>
>> I'm seeing a problem with my setup where the date command fails in an
>> odd way:
>>
>> this is what it does: $ date -d '1 January 1900' date: invalid date `1
>> January 1900'
>>
>> same thing on a linux box: $ date -d '1 January 1900' Mon Jan 1 00:00:00
>> PMT 1900
>>
>> any dates after 1901 seem to work OK: $ date -d '1 January 1902' Wed Jan
>> 1 00:00:00 PMT 1902
>>
>> but nothing works before then:
>>
>> $ date -d 'today - 150 years' date: invalid date `today - 150 years'
>>
>> $ date -d 'today - 100 years' Sun Jan 21 01:33:27 WET 1912
>>
>> this is the info for the date command:
>>
>> $ date --version date (GNU coreutils) 8.14 Packaged by Cygwin (8.14-1)
>> Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU
>> GPL version 3 or later<http://gnu.org/licenses/gpl.html>. This is
>> free software: you are free to change and redistribute it. There is NO
>> WARRANTY, to the extent permitted by law.
>>
>> Written by David MacKenzie.
>>
>> Where should I start debugging?
> Start by finding out exactly when date stops working.
>
> The followijng is the same date version, everything up to date, on
> Windws 7:
>
> /c>  date -d 1901-12-13\ 15:45:52
> Fri, Dec 13, 1901  3:45:52 PM
> /c>  date -d 1901-12-13\ 15:45:51
> date: invalid date `1901-12-13 15:45:51'
> /c>  date -d 1901-12-13\ 15:45:51.999
> date: invalid date `1901-12-13 15:45:51.999'
> /c>  date -d 1901-12-13\ 15:45:52.000
> Fri, Dec 13, 1901  3:45:52 PM
>
> So 1901-12-13 15:45:52 is the earliest that works  Waiting a few minutes
> and repeating does not change this.
>
> When is that in seconds:
>
> /c>  date -d 1901-12-13\ 15:45:52 +%s
> -2147483648
>
> %s give the number of "seconds since 1970-01-01 00:00:00 UTC".  So this
> critical time is 2147483648 seconds before the start of the Unix epoch.
>
> Now -2147483648 = -2^31.  So it looks like cygwin date encodes seconds as
> signed long integers.  Presumably, date on your linux box was compiled to
> use something bigger.
>
> - 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