David Douthitt wrote: > > On 2/5/02 at 10:56 AM, Matt Schalit <[EMAIL PROTECTED]> wrote: > > > Secondly this whole discussion about setting the date > > is a waste of time until David replaces the broken busybox > > date with a working date binary. What good is it to set > > the clock with atomic precision when date doesn't even know > > the difference between GMT and EST? > > I don't program busybox. I don't control busybox. I didn't write > busybox or the busybox date command.
I know. And I remember seeing the post you cc'd to this list from the busybox maintainer who told us of the broken date. I was suggestion you make available a working date.lrp as a package to replace the busybox one. > The "broken date" is only in the reporting of the timezone, as I > remember. If the system is set correctly, it doesn't matter. rdate, > ntpdate, hwclock - they all work just fine - and two of them are in > busybox. As a matter of fact - hwclock is not. I disagree. Hwclock does not function just fine because it's functionality is affected by the broken date it uses as described in the man page I quoted in my other post. I guess you could say that's not hwclock's fault and that it's doing what it's been told to do by a broken date, but it's late and I may be drifting. > > Most programs get the > > date and time wrong, while the other half log with a shifted > > timestamp? The syslog goes kablooie. You have no idea when > > anything happened. > > The programs that get the time wrong are their own problems (not > problems with date) - syslogd, for example, is the full version. Syslogd respects the system clock, and when it can't be set properly via a call to a remote date server, then the problems have started. The system clock and hardware clock and rdate refuse to all agree. Yet I can set this up perfectly in Dachstein or in Lrp 2.9.8. I thought I used to be able to get Oxygen to work perfectly, I think in May2001. That's part of why this has been frustrating. Don't you remeber all the work we did getting the hwclock.sh script hashed out and it was all perfect ( I think in a devel img ). But then you and I drifted away from working on Oxygen when I went on vacation and when the next release of Oxygen came out a couple of months later, the hwclock.sh fixes had reverted back to the old buggy ones and then 2.1.3 and busybox updates and it was never the same again :-/ > ssmtp is ssmtp - if it gets the date wrong, it is its own fault as > long as the timezones are set correctly. Make sure TZ is set and > /etc/localtime points to a file that exists and is correct. Lord knows I've done that a gazillion times. Remember when I pointed out to CS that his web server was transferring the 1000 byte PST8PDT file as ascii and it was ending up as 1005 bytes because he had left his web server defaulting to ascii (messes up .lrp transfers). Plus I can make this work without incident on other distros. > In my mind, the TZ environment variable should be all that is required > - but it would appear things are not that way any more. It used to be > simple... someone had to muck it up. Well maybe the hwclock man page sheds some light in that is says we must call hwclock --hctosys in order to initialize TZ into the kernel. > At worst - things are either in GMT or in localtime. Period. Not entirely. When all my clocks are set for localtime, rdate reports a shifted value when I'm sure the rdate servers isn't. Plus syslog get's it wrong. So the kludge "things are in localtime" doesn't work completely. The value could shift either way. The time subsystems do not behave sanely (as you other post mentions :-) > If it's really bad - forget timezones and set the system hardware time > to local time, not GMT. That's what I always do (though I've tried every other combination I can think of to be thorough). Regards, Matt _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
