> date --version reports 2.0. > > the doc says date -u will set the time in UTC, but it does not work the same > as date -s. For instance, date -s 1401 works fine; date -u 1901 does not. Those two options are independent. -u is not a replacement for -s. -u modifies the behavior of -s, and others, so that time is set as utc time. However, if you include a timezone in the -s timestring then it will take the timezone from the string. date -s 1401 Wed Apr 18 14:01:00 MDT 2001 date -u -s 1401 Wed Apr 18 20:01:00 UTC 2001 But if I include the time zone in the -s string them the -u won't have any effect. You might think of -u as changing the default timezone to UTC for that one command only. However, I think you have uncovered a different bug. date -u -s 1401 Wed Apr 18 20:01:00 UTC 2001 date -u -s '1401 UTC' Wed Apr 18 14:01:00 UTC 2001 I think those two should work exactly the same. But perhaps I am confused as well. The first case assumes 1401 is MDT and converts it to UTC before setting and printing. I think date should assume 1401 is UTC as in the second case. > And I'm still trying to figure out how to fix the clock on a machine that > reports it's still Standard Time (here in the US) and that also reports UTC > wrong by one hour. It's running 1.16. Hmm... You don't say what type of system you are running on and it is hard to predict. HP-UX, IBM AIX and many other traditional SysV UNIX hosts control this through the TZ environment variable. Some Linux versions use /etc/localtime as a copy of the appropriate /usr/share/zoneinfo/* file. It sounds like your timezone is set differently than desired. Depending on your OS varient you would need to read the documentation and configure the zone either for the machine in a system file or in your environment as an environment variable. Bob _______________________________________________ Bug-sh-utils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-sh-utils
