[mythtv-users] time zone with distant frontend

Michael T. Dean mtdean at thirdcontact.com
Wed Dec 30 02:16:21 UTC 2009

On 12/29/2009 08:08 PM, Robert McNamara wrote:
> On Tue, Dec 29, 2009 at 5:02 PM, Eric Sharkey wrote:
>> On Tue, Dec 29, 2009 at 6:20 PM, Robert McNamara wrote:
>>>  This is nothing new-- expect a strong stance
>>> against anything that would be considered theft, a violation of law,
>>> or actionable to continue.
>> Ok, can you seriously say with a straight face that allowing the
>> backend/frontend combo to function properly when the backend and
>> frontend have different TZ configurations would qualify as theft or a
>> violation of the law in any jurisdiction?

No, but I can say with a straight face that Myth currently does /not/ 
work if a master backend and a frontend have different time zone 

What makes Myth /not/ work if a master backend and a frontend have 
different time zone configurations is /not/ the code that makes 
mythfrontend exit.  The code that makes mythfrontend exit simply 
prevents a user from /thinking/ all is good, then having issues when 
trying to use MythTV.

The idea is, "Let's be up front with the user and tell them when their 
system configuration is destined to result in failure of MythTV."

It's exactly the same as Myth's requirement to have a HOME variable 
set.  When we changed Myth to check for HOME and exit if it wasn't set, 
we got a ton of complaints.  We're getting the same for this.  In both 
cases, however, it's simply helping the user to set things up correctly 
so that Myth /will/ work.

If you /really/ want to run a broken configuration that won't work, just 
comment out the line that exits and have fun--and please don't ever 
submit any tickets when things don't work.

>> I think what Brian was reacting to in this discussion was the fact
>> that bringing up rights issues in this discussion is really quite off
>> topic.
> Nobody cast aspersions about *anyone*, merely mentioned it as a
> possible (and IMHO, likely (preceding opinion is my own and not that
> of the MythTV team)) scenario for most people trying to operate
> mythboxes across timezones.  I read Mike's comment as a "I have yet to
> hear of anyone doing this for reasons that sound lawful, legitimate,
> and ethical to me, but when I do, I'll be happy to help them."

That was my intent.  I wasn't saying that Brian was violating ToS--after 
all, Brian just presented a "what if."  Furthermore, I was dismissing 
the "what if" as something I'm not going to consider because in a "what 
if" scenario, the terms of service are undefinable.

I only brought up rights issues because I wanted to be up front about 
the fact that I--and here I'm speaking for myself and not trying to 
speak for the project or anyone else--/will/ flat out refuse to help 
anyone that I know is stealing service or stealing copyrighted content.  
Therefore, if someone were to ask me for help making a system run across 
multiple time zones--something which, with very few exceptions, would be 
in violation of ToS--I'm going to make them prove to me that they are 
allowed to do what they're trying to do before /I/ help them.

On the lists and IRC if I figure out that someone is stealing something, 
I stop helping them.  Sure, IANAL and IA(definitely)NAL(schooled in all 
the world's laws), so I may not interpret the law properly in every 
case, but I can say without any hesitation that in all cases where I 
have refused to help someone because I thought they were stealing 
something, they were doing something that /was/ in violation of my 
ethical beliefs.  If you don't like that, sue me.

Again, though, anyone can figure out what to do without my help as it's 
not a well-hidden secret (and even if it were a secret, it is an open 
source program).

>   The
> ensuing response reads as very hostile and aggressive to me.  It's
> been done before today, and once again-- comparing the devs to nazis
> is nobody's idea of reasonable.
>> If you don't want to spend time working on a feature, that's fine.
>> Just say, "I don't want to do it.".  But to suggest that something
>> shouldn't be done because under some extremely unlikely scenario
>> someone might possibly break the law is somewhat offensive dye to the
>> presumption of guilt on the part of the user.
> Likewise, there is a presumption by users complaining most vehemently
> about this issue that it is in *any* way a simple fix, or that they
> understand what it would take to fix it is foolhardy at best and
> offensive at worst.  So how about we meet in the middle?  It's not an
> easy fix to go to UTC across the board, it's a boatload of work,

and once that work is complete, Myth works /exactly/ the same as it does 
now for any users who configure their systems appropriately except 
things become simpler for 2 hours per year in those areas where DST is 
observed***  (I.e. it's a million steps to get to basically the exact 
same place we currently are.)

>  and
> as a result, nobody wants to do it.  And so, in the end, as they
> say...
> ...
> ...patches welcome.


***Of course, once someone does write code to convert the entire 
architecture to use UTC, all of a sudden we will start getting invalid 
tickets that say, "My frontend says the show starts at 7:00, but my 
backend says it starts as 8:00," or "My frontend says the show was 
recorded at 9:00, but MythWeb says it was recorded at 10:00," or the 
inevitable, "The EPG data is off by 6 hours.  Because of this, I set the 
'Your Local Timezone (for XMLTV)' setting to -0600, but now the EPG data 
is off by 12 hours."  (Where the 3rd case actually caused a user to 
break their system configuration.)

This isn't to say that I won't be happy to rip out the "exit if time 
zones differ" code when someone writes a patch to convert the entire 
architecture to use UTC, but is just acknowledging that at least with 
the current architecture, we won't have those issues mentioned above, 
and users don't have to piece together innumerable disparate clues to 
find out their systems are misconfigured--they figure it out really 
quickly when mythfrontend doesn't run (and, if they bother to look at 
the mythfrontend output or log file, they know exactly why).  The only 
problem is they tend to think that only the current time is important, 
so they think Myth has a bug.


More information about the mythtv-users mailing list