Re: date

[Bob Proulx]

> 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