Bug #3129
DVR Time Schedule records at wrong offset
0%
Description
There seems to be a bug in how times are handled. My server is configured to use UTC
$ date Sat Oct 3 18:50:50 UTC 2015
$ cat /etc/localtime TZif2UTCTZif2UTC UTC0
DVR -> Time Schedules -> Add (new recording).
Set start time to a few minutes in the future, end a few minutes after. 7 days a week, select channel, etc. Save.
Now going to upcoming recording tab, the newly created recording shows. Click edit. The times entered are -4hrs from the times I entered in the previous form. I'm UTC-4.
Seems like Tvheadend knows that the EPG data coming in needs to be -4 since that's my time offset when I setup the grabber, however it's setting the record time to -4hrs from when I enter it. Making all my recordings happen 4 hours earlier than they should be.
History
Updated by Robert Accettura about 9 years ago
Updated by Changed timezone to ET, and now it records on time, so there's clearly some offsetting where there shouldn't be.
Updated by Jaroslav Kysela about 9 years ago
Updated by TVH handles all time data fields in UTC internally. The web interface uses getTime() method for the date object - http://www.w3schools.com/jsref/jsref_gettime.asp which also returns UTC time (without timezone). If the timezone is incorrect on the browser machine, then entered time is not valid, of course. You may check, if time passed to the TVH server is in UTC format.
Updated by g siviero about 9 years ago
Updated by I had a similar problem (EPG showing on air programs that were 2 hours to come) and I resolved as in forum topic 15338 (OTA EPG data timing seems wrong for Australia):
configuration -> DVB Inputs -> Networks, select a network, select Edit. In there, you'll find an option "EIT Local Time" which specifies that your EPG is using local time instead of UTC. Disable it.
The two hours shift only occurred on some channels when the epg grabber scanned the mux and updated the times/listings. System time and tvheadend times are UTC and correct, so there must be some issue with EIT data or the way it gets grabbed. Disabling the "EIT Local Time" seems to solve my problem.