On Sat, 2008-10-04 at 16:26 -0400, William L. Maltby wrote:
> <snip>
> >
> > On centos 4.7
> > --------------
> > test001:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d"
> > 2008-10-26
> > test001:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d"
> > 2008-10-26
>
> I just typed the above in on the console on my 4.7 node. WFM.
>
> > test001:/% uname -a
> > Linux test001... 2.6.9-78.0.1.ELsmp #1 SMP Tue Aug 5 11:02:47 EDT 2008
> > i686 athlon i386 GNU/Linux
>
> My kernel doesn't have the "smp", but otherwise matches.
>
> > <snip>
>
> Another posted the possibility of TZ issues. Seems unlikely to me since
> you are providing a date string that does not require the system time
> zone information. It just converts to the binary offset value from the
> epoch, adds the binary equivalent of a day in seconds (IIRC) and formats
> the results as a string.
>
> Maybe some library (like the ones used by asctime, ctime, ...) which are
> section 3 system calls (those used buy programs like date) are out of
> sync? Have you tried the rpm --verify to see if any discrepancies are
> reported?
BTW, rpm -q --whatprovides /bin/date over here indicates
coreutils-5.2.1-31.8.el4
I've not run the prerequisites for that, but there should be several
specific libraries versions that must be in place. If one or more of
those libraries has been updated from another repositiry or corrupted,
that may be your problem.
Another thought: sometimes folks have a local alias or a similarly named
command in an earlier part of $PATH (e.g. export PATH=$HOME/bin:$PATH)
and then we (they) forget they did that. Or they inherit a system from
another who made a similar modification. "whereis" date should reveal if
that is the case.
--
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
