Why does VDR 1.24 deliver the same wakeup time twice? (Debian-Kernel 2.6.11)
When VDR shuts down, the wakeup time is OK. But after that power on occured and the recording finshed, VDR delivers the same time again. See partial /var/log/syslog below
Too in noticed that the automatically catched "text" for the recording title does (almost?) always belong to the previous program and not to the recorded.
04:05:06 msi vdr[5555]: executing '/video0/pwroff 1117519200 14094 1 "Morgenmagazin" 0' 04:05:06 msi pwroff: VDR shutdown 1:1117519200 2:14094 3:1 4:Morgenmagazin 5:0 04:05:07 msi pwroff: no one logged in 04:05:08 msi pwroff: /proc/acpi/alarm:2005-05-31 06:55:00 Waketime:2005-05-31 06:55:00 04:05:08 msi /video0/pwroff: VDR shutdown delay now 1:1117519200 2:14094 3:1 4:Morgenmagazin 5:0 04:05:08 msi shutdown[7127]: shutting down for system halt 04:05:08 msi init: Switching to runlevel: 0 04:05:08 msi vdr[5555]: max. latency time 60 seconds .. 04:05:22 msi kernel: Kernel logging (proc) stopped. 04:05:22 msi kernel: Kernel log daemon terminating. 04:05:22 msi exiting on signal 15 power off
wakeup
06:56:31 msi syslogd 1.4.1#16: restart. 06:56:31 msi kernel: klogd 1.4.1#16, log source = /proc/kmsg started. ... 06:57:02 msi logger[5429]: starting /root/video/VDR/runvdr 06:57:04 msi kernel: lirc_serial: auto-detected active low receiver 06:57:04 msi kernel: lirc_dev: lirc_register_plugin: sample_rate: 0 06:57:06 msi vdr[5554]: VDR version 1.3.24 started
...recording...
07:32:22 msi vdr[5554]: executing '/video0/pwroff 1117519200 1658 1 "Morgenmagazin" 0' 07:32:22 msi pwroff: VDR shutdown 1:1117519200 2:1658 3:1 4:Morgenmagazin 5:0
07:32:22 msi pwroff: no one logged in 07:32:23 msi pwroff: /proc/acpi/alarm:2005-05-31 06:55:00 Waketime:2005-05-31 06:55:00 07:32:23 msi /video0/pwroff: VDR shutdown delay now 1:1117519200 2:1658 3:1 4:Morgenmagazin 5:0 07:32:23 msi shutdown[6166]: shutting down for system halt 07:32:23 msi init: Switching to runlevel: 0 07:32:23 msi pwroff: has a problem? shutdown failed!
power off
no wake upp... (should have been 10:50)
timer.conf.. Sorry, none. i made that timer a "one shot" and VDR already had deleted it. (Is there no flag to tell VDR *not* to delete one-shots automatically? Somestimes a recoding missmatched teh actual schedule. So it's nice to catch an old one-shot, because EPG does not go very much backwards nor very much into the future.) Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------
On Tuesday 31 May 2005 18:46, Rainer Zocholl wrote:
{snippage}
I saw something like this last week with vdr-1.3.24 but I put it down to the fact that I had pressed power off and confirmed it whilst a timer was still recording (program had finished by then), and the wakeup time was set to the current recording rather than the next recording.
I was going to post that as a bug where the current rather than the next timer is passed to the power-off script when called with a recording active, rather than a separate bug as you seem to have seen!
Had the recording definitely finished?
Cheers,
Laz
laz@club-burniston.co.uk(Laz) 31.05.05 20:26
{snippage}
I saw something like this last week with vdr-1.3.24
Sorry, i meant 1.*3*.24! (see logfile)
Had the recording definitely finished?
At 4:00 or 7:30 i'm not playing with remote control anymore ;-) The box was stopping, starting and again stopping completely on it's own.
Rainer
Two problems: 1. Using wrong timer 2. Handing wrong time
VDR 1.3.25 (2.6.11) should start at 7:00, but the clock was set to 5:55 The next start was again set to 5:55
That timer was inactive! 0:S19.2E-1-1101-28112:MTWTFSS:0600:0615:50:7::
That timer string was used. 1:S19.2E-1-1079-28006:MTWTF--:0700:0715:40:1:ARD-Morgenmagazin:
Is the time "UTC" based?
No recording was done.
The next start was again issued for the same time, which is now in the past, impossible to do. nvram-wakeup would have rejected that time so this error would have not caused a missed recording. Currently i'm using an other script to test "acpi" and no validation is done, just logged.
It looks like VDR is using the wrong time, maybe wrong time zone or inconsequent time zone?
msi:~/work# tzconfig Your current time zone is set to CET Do you want to change that? [n]: y ... Your default time zone is set to 'Europe/Berlin'. Local time is now: Wed Jun 1 08:49:28 CEST 2005. Universal Time is now: Wed Jun 1 06:49:28 UTC 2005.
msi:~/work# date Wed Jun 1 08:52:07 CEST 2005
Was there a change in VDR?
Jun 1 02:08:59 msi /video0/pwroff: VDR shutdown delay now 1:1117602000 2:17463 3:2 4:ARD-Morgenmagazin 5:0 A:1117602000 1746 3 2 ARD-Morgenmagazin 0 Jun 1 05:58:53 msi vdr[5721]: channel 1 (Das Erste) event 05:30 'Morgenmagazin' status 4 Jun 1 05:58:57 msi vdr[5717]: timer 36 (2 0700-0715 'ARD-Morgenmagazin') set to event Wed 01.06.2005 05:30-09:00 (VPS: 01.06 Jun 1 02:08:57 msi vdr[12144]: executing '/video0/pwroff 1117602000 17463 2 "ARD-Morgenmagazin" 0' Jun 1 02:08:57 msi pwroff: VDR shutdown 1:1117602000 2:17463 3:2 4:ARD-Morgenmagazin 5:0 A:1117602000 17463 2 ARD-Morgenmaga zin 0 Jun 1 02:08:59 msi /video0/pwroff: VDR shutdown delay now 1:1117602000 2:17463 3:2 4:ARD-Morgenmagazin 5:0 A:1117602000 1746 3 2 ARD-Morgenmagazin 0 Jun 1 05:58:53 msi vdr[5721]: channel 1 (Das Erste) event 05:30 'Morgenmagazin' status 4 Jun 1 05:58:57 msi vdr[5717]: timer 36 (2 0700-0715 'ARD-Morgenmagazin') set to event Wed 01.06.2005 05:30-09:00 (VPS: 01.06 05:30) 'ARD-Morgenmagazin'
msi:~# date -d "1970-01-01 1117602000 sec" Wed Jun 1 06:00:00 CEST 2005
Patches: (IIRC) LNBsharing femon-09 stuttering vdr stuttering plug ins: femon osd teletext (undelete does not compile)
En/na Rainer Zocholl ha escrit:
Is the time "UTC" based?
In vdr no, but only you know how you configured your cmos clock (that is used by acpi wakeup). If it is configured in utc you have to convert the time supplied by vdr to utc (unix2iso8601 -u). I think that's documented in acpi-wakeup.
Bye
luca@ventoso.org(Luca Olivetti) 01.06.05 09:22
Once upon a time "Luca Olivetti " shaped the electrons to say...
En/na Rainer Zocholl ha escrit:
Is the time "UTC" based?
In vdr no, but only you know how you configured your cmos clock (that is used by acpi wakeup).
No. linux does know to too ;-) At least t says the clocj is "local time" and asks me if i which to change it.
Yes. But i assume that VDR is going with UTC(!) or the wrong tiemzone into the timers table if it determine what should be record next, or makes an error when converting to epoch seconds. Or why do i get the wrong time?
Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------
/video0/pwroff get the parameters from VDR: VDR shutdown delay now 1:1117634400 2:3702 3:88 4:Do It Yourself - S.O.S. 5:0
that is time msi:~/video# date -d "1970-01-01 1117634400 sec" Wed Jun 1 15:00:00 CEST 2005
the timer is: msi:~/video# grep Yourself /video0/timers.conf 1:T-8468-8705-16403:MTWTF--:1600:1701:50:3:Do It Yourself - S.O.S.:
Jun 1 15:15:56 msi vdr[5722]: executing '/video0/pwroff 1117634400 2644 88 "Do It Yourself - S.O.S." 0' Jun 1 15:15:56 msi pwroff: VDR shutdown 1:1117634400 2:2644 3:88 4:Do It Yourself - S.O.S. 5:0 A:1117634400 2644 88 Do It Yourself - S.O.S. 0 Jun 1 15:15:57 msi pwroff: wrong wakeup time 1117634400!
It seems that VDR finds the right timer, but calcutes the time in second wrong!
Again: The most beloved problem: Reentrancy...
cString TimeToString(time_t t) { char buffer[32]; if (ctime_r(&t, buffer)) { buffer[strlen(buffer) - 1] = 0; // strip trailing newline return buffer; } return "???"; }
It's no good idea to deference a variable on the stack OUTSIDE the function it self... It might work but is not really better than a static and is not relyable!
Having a deja vue: I thought all that was "overworked" with the "thread-save" patches 3 month ago?
ere old soruces fed back to cvs?
Making it "static" violates multithreading...
the fastest: Make it like in ctime_r an define a buffer pint as parameter the slowest: use the ugly aprintf and don't forget to free the memory...
Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------
On Wed, 1 Jun 2005, Rainer Zocholl (RZ) wrote:
RZ> RZ> that is time RZ> msi:~/video# date -d "1970-01-01 1117634400 sec" RZ> Wed Jun 1 15:00:00 CEST 2005 RZ> RZ> the timer is: RZ> msi:~/video# grep Yourself /video0/timers.conf RZ> 1:T-8468-8705-16403:MTWTF--:1600:1701:50:3:Do It Yourself - S.O.S.: RZ> RZ> RZ> RZ> Jun 1 15:15:56 msi vdr[5722]: executing '/video0/pwroff 1117634400 2644 88 RZ> "Do It Yourself - S.O.S." 0' RZ> Jun 1 15:15:56 msi pwroff: VDR shutdown 1:1117634400 2:2644 3:88 4:Do It RZ> Yourself - S.O.S. 5:0 A:1117634400 2644 88 Do It Yourself - S.O.S. 0 RZ> Jun 1 15:15:57 msi pwroff: wrong wakeup time 1117634400! RZ> RZ> RZ> It seems that VDR finds the right timer, but calcutes the time RZ> in second wrong!
the calculated time IS correct. you can use the small tool 'time' from nvram-wakeup package:
# ./time 1117634400 (time_t) 1117634400 (local time) Wed Jun 1 16:00:00 2005 (utc/gmt) Wed Jun 1 14:00:00 2005
or, if you trust 'date', use this:
# date +%s -d "Wed Jun 1 16:00:00 CEST 2005" 1117634400
c ya Sergei
Sergei.Haller@math.uni-giessen.de(Sergei Haller) 01.06.05 16:22
On Wed, 1 Jun 2005, Rainer Zocholl (RZ) wrote:
RZ>> RZ>> that is time RZ>> msi:~/video# date -d "1970-01-01 1117634400 sec" RZ>> Wed Jun 1 15:00:00 CEST 2005 RZ>> RZ>> the timer is: RZ>> msi:~/video# grep Yourself /video0/timers.conf RZ>> 1:T-8468-8705-16403:MTWTF--:1600:1701:50:3:Do It Yourself - RZ>> S.O.S.: RZ>> RZ>> RZ>> RZ>> Jun 1 15:15:56 msi vdr[5722]: executing '/video0/pwroff RZ>> 1117634400 2644 88 "Do It Yourself - S.O.S." 0' RZ>> Jun 1 15:15:56 msi pwroff: VDR shutdown 1:1117634400 2:2644 3:88 RZ>> 4:Do It Yourself - S.O.S. 5:0 A:1117634400 2644 88 Do It Yourself RZ>> - S.O.S. 0 Jun 1 15:15:57 msi pwroff: wrong wakeup time RZ>> 1117634400! RZ>> RZ>> RZ>> It seems that VDR finds the right timer, but calcutes the time RZ>> in second wrong!
the calculated time IS correct. you can use the small tool 'time' from nvram-wakeup package:
or, if you trust 'date',
Only! ;-)
use this:
# date +%s -d "Wed Jun 1 16:00:00 CEST 2005" 1117634400
If i use the unix tool "date" i get
msi:~/video/VDR# date -d "1970-01-01 1117634400 sec" Wed Jun 1 15:00:00 CEST 2005
And on the other way:
msi:~/video/VDR# date +%s -d "Wed Jun 1 16:00:00 CEST 2005" 1117634400
Intessting, isn't it?
But: msi:~/video/VDR# date -d "1970-01-01 1117634400 sec GMT" Wed Jun 1 16:00:00 CEST 2005
Funny?
So for what ever reasons, VDR delivers "GMT" and not "localtime"! Or does "date" make an error?
Where is the 1h(!) offest from? We have Summertime (OK, curently only in the computer, not ouside) that's "GMT+2h"
At least adding "GMT" would be a workarround, thanks to the hint.
Anyway: The functions TimeToString, DateToString are not cleanly implemented! One should never return a pointer to local stack back the calling(!) programm. It causes very very very mean hard to detect very ugly errors. One effect: Using compiler A all is well, compiled with B does not work relyable. Using in ten calls type a works, using in an other contens does not work. And of cause, with preemtive multitasks there are more problems.
Rainer
On Wed, 1 Jun 2005, Rainer Zocholl (RZ) wrote:
RZ> > # ./time 1117634400 RZ> > (time_t) 1117634400 RZ> > (local time) Wed Jun 1 16:00:00 2005 RZ> > (utc/gmt) Wed Jun 1 14:00:00 2005 RZ> RZ> >or, if you trust 'date', RZ> RZ> Only! ;-) RZ> RZ> >use this: RZ> RZ> > # date +%s -d "Wed Jun 1 16:00:00 CEST 2005" RZ> > 1117634400 RZ> RZ> If i use the unix tool "date" i get RZ> RZ> msi:~/video/VDR# date -d "1970-01-01 1117634400 sec" RZ> Wed Jun 1 15:00:00 CEST 2005 RZ> RZ> And on the other way: RZ> RZ> msi:~/video/VDR# date +%s -d "Wed Jun 1 16:00:00 CEST 2005" RZ> 1117634400 RZ> RZ> Intessting, isn't it?
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.
RZ> So for what ever reasons, VDR delivers "GMT" and not "localtime"! RZ> Or does "date" make an error?
no, see above.
date, time, vdr: all compute the time_t values correctly.
c ya Sergei
Sergei.Haller@math.uni-giessen.de(Sergei Haller) 01.06.05 16:22
RZ>> It seems that VDR finds the right timer, but calcutes the time RZ>> in second wrong!
the calculated time IS correct. you can use the small tool 'time' from nvram-wakeup package:
or, if you trust 'date', use this:
# date +%s -d "Wed Jun 1 16:00:00 CEST 2005" 1117634400
I forgot to copy that test done here:
msi:~/video/nvram/nvram-wakeup# ./time 1117634400 (time_t) 1117634400 (local time) Wed Jun 1 16:00:00 2005 (utc/gmt) Wed Jun 1 14:00:00 2005
But why:
# 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 # date -d "1970-01-01 1117634400 sec GMT" Wed Jun 1 16:00:00 CEST 2005 # date -d "1970-01-01 1117634400 sec WET" Wed Jun 1 16:00:00 CEST 2005
Rainer
Rainer Zocholl a écrit :
If time-zone is applied to the date supplied, CEST in january is UTC+1, the same as CET... You're cheating "date", as Sergei stated...
One way not to cheat with date : $ perl -e 'print scalar(localtime(1117634400)),"\n"' Wed Jun 1 16:00:00 2005 $ perl -e 'print scalar(gmtime(1117634400)),"\n"' Wed Jun 1 14:00:00 2005
localtime() in perl does not take timezone into account at all. Whereas gmtime() uses the local timezone to convert the result in GMT.
On Wed, 1 Jun 2005, Rainer Zocholl (RZ) wrote:
RZ> RZ> >the calculated time IS correct. you can use the small tool 'time' from RZ> >nvram-wakeup package: RZ> RZ> > # ./time 1117634400 RZ> > (time_t) 1117634400 RZ> > (local time) Wed Jun 1 16:00:00 2005 RZ> > (utc/gmt) Wed Jun 1 14:00:00 2005 RZ> RZ> >or, if you trust 'date', use this: RZ> RZ> > # date +%s -d "Wed Jun 1 16:00:00 CEST 2005" RZ> > 1117634400 RZ> RZ> RZ> I forgot to copy that test done here: RZ> RZ> msi:~/video/nvram/nvram-wakeup# ./time 1117634400 RZ> (time_t) 1117634400 RZ> (local time) Wed Jun 1 16:00:00 2005 RZ> (utc/gmt) Wed Jun 1 14:00:00 2005 RZ> RZ> RZ> But why:
try reading documentation on time_t (e.g. in glibc manual)
again, the following commandos _do_not_ convert time_t back to human readable format. unfortunately (AFAIK), date has only the way humanreadable -> time_t (see example above)
RZ> # date -d "1970-01-01 1117634400 sec CET" RZ> Wed Jun 1 15:00:00 CEST 2005 RZ> # date -d "1970-01-01 1117634400 sec CEST" RZ> Wed Jun 1 15:00:00 CEST 2005 RZ> # date -d "1970-01-01 1117634400 sec GMT" RZ> Wed Jun 1 16:00:00 CEST 2005 RZ> # date -d "1970-01-01 1117634400 sec WET" RZ> Wed Jun 1 16:00:00 CEST 2005
Sergei
Sergei.Haller@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"
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
Rainer Zocholl a écrit :
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à...
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
Sergei.Haller@math.uni-giessen.de(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.
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...)
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.
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 ------------
On Thu, 2 Jun 2005, Rainer Zocholl (RZ) wrote:
RZ> Sergei.Haller@math.uni-giessen.de(Sergei Haller) 02.06.05 11:56 RZ> RZ> >they could have implemented a thing like RZ> RZ> > date -d "946684800" RZ> RZ> >THEN it would be intended. RZ> RZ> but when one uses 2000-01-01 (to save bits) as epoch he lost?
???
RZ> RZ> Yes, if everybody uses 1970-01-01 as base.
that's part of the definition of time_t.
RZ> It'll last not very long anymore and many many unix may crash RZ> because the systemtime in seconds "wraps"..
that's a completely different problem. unrelated to VDR too.
RZ> Compared to this the Y2K problem was just a joke, because mainly RZ> a "display" problem,
no, Y2K wasn't just a "display" problem, but again, this is OT.
back to your original question:
yes, VDR computes the time_t values correctly, as, I think, I was able to show using "time" and "date" in my first post in this thread.
c ya, Sergei
Rainer Zocholl wrote:
Well, why should they crash, the time just wraps?
Also note that this doesn't affect 64-bit systems: http://www.2038bug.com/64-bit.html
-
Anssi Hannula -
Laz -
Luca Olivetti -
Nicolas Huillard -
Rainer Zocholl -
Sergei Haller