On Wed, 1 Jun 2005, Rainer Zocholl (RZ) wrote:
RZ> date -u -d '1970-01-01 946684800 seconds' +"%Y-%m-%d %T %z" RZ> 2000-01-01 00:00:00 +0000 RZ> RZ> RZ> I don't see why this is a "cheat" (= not intended way of usesage)
they could have implemented a thing like
date -d "946684800"
THEN it would be intended. it would take the _unique_ point in time 946684800 and print it as a string corresponding to this _unique_ point in time. The output would of course depend on your time zone or the option -u. But the input would not, since it is time zone independant.
as you can see on your own examples, the way it is implemented now _does_not_ convert the _unique_ point in time 1117634400 to the human readable format of this _unique_ point in time.
RZ> The man page example is missleading. RZ> date will interpret the "1970-01-01" with the current timezone... RZ> RZ> It must read: RZ> # date -d "1970-01-01 UTC 1117634400 sec" RZ> Wed Jun 1 16:00:00 CEST 2005 RZ> as the "-utc" relates to output. RZ> # date -u -d "1970-01-01 UTC 1117634400 sec" RZ> Wed Jun 1 14:00:00 UTC 2005
on the first sight, the option -u only changes the output, BUT it also changes the assumed timezone if no timezone is given.
so date -u -d "1970-01-01 UTC 1117634400 sec" date -u -d "1970-01-01 1117634400 sec" are the same: Wed Jun 1 14:00:00 UTC 2005 which is correct: date +%s -d "Wed Jun 1 14:00:00 UTC 2005" 1117634400
RZ> But i still do not undestand why here is a 1h offset RZ> if nothing is given. RZ> I would assuem that the timezone would be komensated RZ> # date -d "1970-01-01 1117634400 sec" RZ> Wed Jun 1 15:00:00 CEST 2005
and you will never know, if you don't know which time zone "date" assumes in the input.
Sergei