[vdr] Re: timer problem

[Nicolas Huillard]

Rainer Zocholl a écrit :
> Sergei.Haller at math.uni-giessen.de(Sergei Haller)  01.06.05 17:16
> 
>>no. time_t is the number of seconds since 1970-01-01 in UTC.
>>a time value as time_t is _unique_.
> 
>>the call
>>  date  -d  "1970-01-01 1117634400 sec"
> 
>>is _not_ translation from time_t to human readable time.
>>you are kind of "cheating" telling date to recalculate the time
>>"1970-01-01 00:00:1117634400" in whatever time zone it expectes it.
> 
> That "cheat" is documented in some man pages for (GNU) "date".

Well, it seems that using "date" adds the complexity of time-zone 
handling to the simple date-difference calculation. There is the 
from-TZ, the to-TZ, the fact that summer-time is either applied to the 
date you provide (1970-01-01) or the date resulting from the calculation 
(now in "summer")...
Avoid the problem is one way to solve it : just make sure you do not 
deal with time-zones when you want to make date calculations. Your 
samples with UTC *and* --utc seems all correct...
Then apply you time-zone adjustments, or consider your clock 
(hardware-clock) is UTC (as recommended by every Linux admin), and voilà...

> "info date" says:
> 
>    * To convert a date string to the number of seconds since the epoch
>      (which is 1970-01-01 00:00:00 UTC), use the `--date' option with
>      the `%s' format.  That can be useful in sorting and/or graphing
>      and/or comparing data by date.  The following command outputs the
>      number of the seconds since the epoch for the time two minutes
>      after the epoch:
> 
>           date --date='1970-01-01 00:02:00 +0000' +%s 
>           120
> 
>      If you do not specify time zone information in the date string,
>      `date' uses your computer's idea of the time zone when
>      interpreting the string.  For example, if your computer's time
>      zone is that of Cambridge, Massachusetts, which was then 5 hours
>      (i.e., 18,000 seconds) behind UTC:
> 
>           # local time zone used
>           date --date='1970-01-01 00:02:00' +%s
>           18120
> 
>    * If you're sorting or graphing dated data, your raw date values may
>      be represented as seconds since the epoch.  But few people can
>      look at the date `946684800' and casually note "Oh, that's the
>      first second of the year 2000 in Greenwich, England."
> 
>           date --date='2000-01-01 UTC' +%s
>           946684800
> 
>      An alternative is to use the `--utc' (`-u') option.  Then you may
>      omit `UTC' from the date string.  Although this produces the same
>      result for `%s' and many other format sequences, with a time zone
>      offset different from zero, it would give a different result for
>      zone-dependent formats like `%z'.
> 
>           date -u --date=2000-01-01 +%s
>           946684800
> 
> 
>      *To convert such an unwieldy number of seconds back to a more*
>      *readable form, use a command like this:*
> 
>           # local time zone used
>           date -d '1970-01-01 UTC 946684800 seconds' +"%Y-%m-%d %T %z"
>           1999-12-31 19:00:00 -0500
> 
>      Often it is better to output UTC-relative date and time:
> 
>           date -u -d '1970-01-01 946684800 seconds' +"%Y-%m-%d %T %z"
>           2000-01-01 00:00:00 +0000
> 
> 
> I don't see why this is a "cheat" (= not intended way of usesage) 
> and why it should be required to have "self programming" such function. 
> Of cause the risc of errors is low if all use exactly teh same
> routine.
> 
>  
> 
> The man page example is missleading.
> date will interpret the "1970-01-01" with the current timezone...
> 
> It must read:
> # date     -d  "1970-01-01 UTC 1117634400 sec"
> Wed Jun  1 16:00:00 CEST 2005
> as the "-utc" relates to output.
> # date -u  -d  "1970-01-01 UTC 1117634400 sec"
> Wed Jun  1 14:00:00 UTC 2005
> 
> But i still do not undestand why here is a 1h offset
> if nothing is given. 
> I would assuem that the timezone would be komensated
> # date -d  "1970-01-01  1117634400 sec"
> Wed Jun  1 15:00:00 CEST 2005
> 
> 
> 
> 
> BTW:
> # date  -u -d  "1970-01-01 1117634400 sec "
> Wed Jun  1 14:00:00 UTC 2005
> 
> # date  -u -d  "1970-01-01 1117634400 sec GMT"
> Wed Jun  1 14:00:00 UTC 2005
> 
> # date   -d  "1970-01-01 1117634400 sec GMT"
> Wed Jun  1 16:00:00 CEST 2005
> 
> 
> 
> # date -u -d  "1970-01-01 1117634400 sec CEST"
> Wed Jun  1 12:00:00 UTC 2005
> # date -u -d  "1970-01-01 1117634400 sec CET"
> Wed Jun  1 13:00:00 UTC 2005
> Two different times...
> 
> # date  -u -d  "1970-01-01 1117634400 sec MET"
> Wed Jun  1 13:00:00 UTC 2005
> # date  -u -d  "1970-01-01 1117634400 sec MEST"
> Wed Jun  1 12:00:00 UTC 2005
> Two different times...
> 
> 
> # date  -d  "1970-01-01 1117634400 sec CET"
> Wed Jun  1 15:00:00 CEST 2005
> # date  -d  "1970-01-01 1117634400 sec CEST"
> Wed Jun  1 15:00:00 CEST 2005
> One time ...
> 
> # date  -u  -d  "1970-01-01      1117634400 sec" +"%D %T %z %Z"
> 06/01/05 14:00:00 +0000 UTC
> # date  -u  -d  "1970-01-01 UTC  1117634400 sec" +"%D %T %z %Z"
> 06/01/05 14:00:00 +0000 UTC
> # date  -u  -d  "1970-01-01 MET  1117634400 sec" +"%D %T %z %Z"
> 06/01/05 13:00:00 +0000 UTC
> # date  -u  -d  "1970-01-01 MEST 1117634400 sec" +"%D %T %z %Z"
> 06/01/05 12:00:00 +0000 UTC
> # date      -d  "1970-01-01      1117634400 sec" +"%D %T %z %Z"
> 06/01/05 15:00:00 +0200 CEST
> # date      -d  "1970-01-01 UTC  1117634400 sec" +"%D %T %z %Z"
> 06/01/05 16:00:00 +0200 CEST 
> 
> # date      -d  "1970-01-01 MET  1117634400 sec" +"%D %T %z %Z"
> 06/01/05 15:00:00 +0200 CEST
> # date      -d  "1970-01-01 MEST 1117634400 sec" +"%D %T %z %Z"
> 06/01/05 14:00:00 +0200 CEST
> 
> # date      -d  "1970-01-01  1117634400 sec CEST" +"%D %T %z %Z"
> 06/01/05 15:00:00 +0200 CEST
> # date      -d  "1970-01-01  1117634400 sec CET" +"%D %T %z %Z"
> 06/01/05 15:00:00 +0200 CEST
> 
> 
> That looks like "MEST" is defined other than "CEST"?

-- 
NH