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