[mythtv] enabling use of guide data from different time zones without additional configuration in mythtv

[Robert Johnston]

On 27/10/2010 1:09 AM, Karl Dietz wrote:
> Hi,
>
> I propose to change the default for "TimeOffset" from "None" to "Auto"
> or preferably even dropping the setting completely. Obviously this
> comes a bit late for mythtv-0.24, no worries on that one.
>
> I'm currently looking at a bug report of a user who wants to use the
> guide from tv_grab_huro in the netherlands. The time zones are EET for
> the guide and CET for the backend.
>
> The default setting for "TimeOffset" in MythTV is "None" which lets
> mythfilldatabase drop the explicit offset from the guide and interpret
> it as local time in the backends time zone. Resulting in programs that
> are off by the one hour that the time zones are different.
>
> The setting "Auto" will honour the exlicit offset and add the local
> offset. But it has a bug relating to programs around the DST change.
> see http://svn.mythtv.org/trac/ticket/8217
>
> As the XMLTV schema does not allow floating time there is no reason
> for such guesswork making the "TimeOffset" setting unneccesary.
> Let's ignore possible bugs in individual grabbers for now, especially
> relating to the day of the DST switchover. But then, the stations get
> them wrong more often then not, too. Especially when there's no useable
> way to say "2:30 in the morning on october 31st" if that can be either
> CET or CEST but you just don't know. (officialy that is 2a o'clock
> CEST and 2b o'clock CET, but good luck using that in any program :)
>
>
> Pseudocode for simplified datetime handling in fromXMLTVDate() matching
> attached patch:
> * take xmltv time and split it into time and time offset (same as now)
> * create UTC timestamp (add explicit UTC, it's implicit localtime now)
> * adjust for explicit offset (always, it's just for "Auto" now. if it's
> not given that's implicit UTC, so no adjustment needed)
> * convert to localtime (use Qt function instead of custom ones)
>
>
> Con: Some guide sources are going to break, especially the ones that
> emit floating localtime when the schema says it's implicit UTC
> timestamps. (it's a violation of the guide schema and the guides I'm
> aware of are of questionable quality anyway)
>
> Pro: No more need to confuse users with crude hacks that break twice a
> year or to tell them to mess with defaults when they want nothing
> special. (see http://google.com/search?q=auto+xmltv+time+zone+mythtv )
> On the other hand a new user can just setup tv_grab_combiner combining
> guides from multiple time zones via mythtv-setup and it's just going to
> work.
> Target audience are all australian users, everyone who moved across a
> time zone border and wants to what tv from home, any europeans wanting
> to watch e.g. BBC (it's in another zone for most of us).

This is a good idea (I make sure that every backend I use is set to 
"Auto" as a matter of course), but a better idea, especially in light of 
the DST problems with it, is to convert Myth to use UTC for all it's 
timings. This would solve pretty much all the problems with DST. Combine 
that with this and both timezone and Daylight Savings problems would be 
pretty much a thing of the past.

Of course, Converting the code to UTC is a little more involved than 
just switching a default value, but it really shouldn't be that involved.