From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: problem with 'date' (sh-utils 2.0.11)
Date: 8 Aug 2002 14:28:00 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 41
Message-ID: <aitv5g$6lu$1@nets3.rz.RWTH-Aachen.DE>
References: <20020807123616 DOT GA1905 AT kendall DOT sfbr DOT org> <Pine DOT SUN DOT 3 DOT 91 DOT 1020808081238 DOT 4988E-100000 AT is> <20020808132249 DOT GA9185 AT kendall DOT sfbr DOT org>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 1028816880 6846 137.226.32.75 (8 Aug 2002 14:28:00 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 8 Aug 2002 14:28:00 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

JT Williams <jeffw AT darwin DOT sfbr DOT org> wrote:
> Yes, that seems quite possible.  Our time_t is 'unsigned int' and
> (according to `man types') my Solaris box typedef's it to 'long'.  OTOH,
> ISTR having the same problem even without the "+%s" format, 

'date' is essentially not much more than a (clever, humane) interface
to the <time.h> function, and time_t is the foundation of those.  So
it should be expected that a value which doesn't fit in a time_t will
not work with 'date', either.  Regardless of the time format used for
output.

> which might suggest that the type of time_t is not an issue (unless
> 'date' does some internal conversion elsewhere for which our time_t
> is a problem).

Furthermore, there seems to be a documentation error in that section you
quoted about +%s not being affected by a --date argument.  Watch this, on
a Linux box near me:

~ $ date --date '2002-01-01' +'%s'
1009839600
~ $ date --date '2002-08-01' +'%s'
1028152800

Clearly, the outputs differ, i.e. %s does see the change of --date.

~ $ date --version                
date (GNU sh-utils) 2.0
Written by David MacKenzie.

Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

'info date' claims '%s' should not react to --date, but the manpage
doesn't.  Seems the manpage is right, in this case.


-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.