Sergei.Haller@xxxxxxxxxxxxxxxxxxx(Sergei Haller) 02.06.05 11:56
>On Wed, 1 Jun 2005, Rainer Zocholl (RZ) wrote:
RZ>> date -u -d '1970-01-01 946684800 seconds' +"%Y-%m-%d %T
RZ>> %z" 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.
but when one uses 2000-01-01 (to save bits) as epoch he lost?
Or need an other parameter to define the epoch?
IMHO the idea of "date" was genious simple.
If the implementation is Ok is another problem.
>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.
Yes, if everybody uses 1970-01-01 as base.
It'll last not very long anymore and many many unix may crash
because the systemtime in seconds "wraps"..
# date -u -d '1970-01-01 UTC 2147483647 seconds' +"%Y-%m-%d %T"
2038-01-19 03:14:07
# date -u -d '1970-01-01 UTC 2147483648 seconds' +"%Y-%m-%d %T"
1901-12-13 20:45:52
Compared to this the Y2K problem was just a joke, because mainly
a "display" problem,
in binary there is not much difference between
1999-12-31 an 2000-01-01.
But there are still 33 years left...
(but Y2K did come very "sudden" and "surprising" too)
(But who is today programming may place the booby trap for 2038,
when he will be retired...)
>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.
At least it's hard to understand what's going there.
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.
yepp. the example MUST read:
# date -d "1970-01-01 UTC 1117634400 sec"
as the epoch IS starting "1970-01-01 UTC 00:00.00"
and not "local timezone"!
Rainer---<=====> Vertraulich
//
//
<=====>--------------ocholl, Kiel, Germany ------------
