[mythtv-users] MythTV does not handle daylight savings properly

Michael T. Dean mtdean at thirdcontact.com
Mon Nov 5 21:36:55 UTC 2012

On 11/05/2012 01:55 PM, Gary Buhrmaster wrote:
> On Mon, Nov 5, 2012 at 10:16 AM, Brian J. Murrell wrote:
> ....
>> If every custom record rule needs every time specification in them
>> converted to/from UTC, that should be done internally, IMHO.
> There is no way to know the true intent behind custom rules.
> And while **some** custom rules might have been able to be
> automagically converted, no one contributed that code (or
> the dialog that would have been required for upgrade such
> as "Conversion of rule x is now<whatever>, is that correct?"),
> and now that pony has left the building...
> Custom rules give great power.  They also come with great
> responsibility.  And that includes TZ issues.

Besides, users have been crying out for us to convert MythTV's internal 
time storage to UTC for years, now--all because they were upset that a 
couple times per year they had to think for a couple seconds to figure 
out proper start early/end late overrides required to make sure that any 
show that aired on DST changeover would record properly (and, perhaps, 
to save them running a lossless transcode to cut off the extra time they 
put in to those DST-changeover recordings for safety).  And since we all 
know just how many good shows are on at 2:00am, especially on the 2 days 
of the year that DST changes occur, I'm sure you understand why it's a 
good idea to give up ease-of-use on 99.98% of the year so that people 
can record their late-night infomercials easily on that other 0.02%.

We've been told by the users that any sane program uses UTC, and that it 
was a travesty that MythTV didn't.  So, now the users have what they've 
been asking for.  I'd hate to think that maybe the users were demanding 
something without understanding the consequences...

That said, custom/power recording rules are an advanced feature for 
advanced users.  Eventually, we'll rewrite the entire interface to 
shield the user from not only the issue of time conversion, but--even 
worse as far as user-friendliness goes--from having to know a) SQL, b) 
the MythTV schema, c) the MythTV data constraints, d) exactly how the 
fragment they create gets to the database (i.e. how to write it so that 
it doesn't break the /extremely/ important scheduler query it gets 
inserted into).

In the interim, you'll notice that /all/ of the example clauses show the 
proper SQL for the conversion, and since >99.9% of users probably never 
use power rules for anything that's not possible with those example 
clauses, I'd argue that it's not much more difficult to use than it was 
before the change.  And that doesn't even take into account the fact 
that the vast majority of power recording rules probably shouldn't even 
be using times (i.e. for the same reason that users should choose "any 
time" rules over "time slot" rules when scheduling with the normal 
interface--because what should matter is that you record the show you 
want, not what time it was when you recorded it).


More information about the mythtv-users mailing list