timer problem (was: Re: [vdr] Re: vdr 1.3.25 thread problems)

Rainer Zocholl UseNet-Posting-Nospam-74308- at zocki.toppoint.de
Wed Jun 1 20:39:00 CEST 2005


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".

"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"?


Rainer




More information about the vdr mailing list