[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.
Mike
More information about the mythtv-users
mailing list