[mythtv-users] duplicate recordings

Michael T. Dean mtdean at thirdcontact.com
Sun Oct 9 18:23:35 UTC 2011

On 10/09/2011 01:42 PM, Mike Perkins wrote:
> On 09/10/11 18:20, Dan Armbrust wrote:
>> Of course, then again, I'm complaining about the scheduler that can't
>> figure out that DST happens twice a year, and completely hoses itself
>> every time that switch happens.  Guess I shouldn't expect much here
>> either.
> For you, maybe. I should imagine the majority of users like myself have no
> problems at all.

Exactly, Mike.  It always does exactly what the rules tell it to do.  
However, it just doesn't account for the fact that the system time will 
change in the middle of the recording.  So, you just have to take that 
into account if you're recording a program that starts at/crosses/ends 
at the local boundary.

Don't worry, though--it will eventually be changed to store all data in 
UTC-a /large/ effort with almost no benefit that is sure to cause bugs 
for months after the change (likely even for users who only run stable 
MythTV).  Then, we won't have to listen to people complain (without 
submitting patches, no less) about how "MythTV should use UTC."  Also, 
it will mean that those of you who directly access data in the database 
will be nice and confused.  :)

Note, also, that MythTV was /explicitly/ designed to use local time in 
the database.  This is not an oversight.  This is not a bug.  This was a 
design decision that was made specifically because it had many benefits 
and the only disadvantage happened during a time period of a maximum of 
2 hours per year--that's 1/4380th of the year where a user has to think 
(and only those users in areas with DST and only those users who 
actually record something that airs at the time of the DST switch).

Of course, my statement that it will change to UTC presupposes that 
we'll actually have a time zone database in the future--since there 
currently exists none for *nix systems.


More information about the mythtv-users mailing list