On 12/29/2009 04:57 PM, Eric Sharkey wrote:
> On Tue, Dec 29, 2009 at 4:34 PM, Michael T. Dean wrote:
>>> Yes, and it applies in /all/ other cases when MythTV applications refuse to
>> run due to differences between the time zone configured on the master
>> backend and the process that's attempting to connect to that backend.
>>>> In other words, the code works as designed /and/ as required.
>>>> Is it really too much to ask that people configure their systems properly?
>>> It doesn't seem like it should need to be that way, though.
>> Naively, if I were designing the system from scratch, I'd have the
> backend deal exclusively in UTC and have the frontends do time
> conversion when necessary for display purposes.
Thus my comment in the linked post (
http://www.gossamer-threads.com/lists/mythtv/users/414900#414900 ,
again, so people can actually decide to read it this time) about how
anyone who dislikes the current configuration can spend a ton of their
own time writing a ton of patches to change the entire MythTV
architecture to use UTC.
When MythTV was originally designed, the decision was made to use local
time for storage of program listings information because it worked
extremely well with all XMLTV grabbers available at the time /and/ it
allowed the devs who created MythTV the ability to easily find
information in the database when debugging without having to do UTC
conversions in their heads.
Anyone is welcome to change Myth to use UTC for everything, but it's a
/huge/ job, and--as I explained in my other message, we have a /lot/ of
other bugs that can have an effect on people at /any/ time during the
year versus this one issue which can only possibly have an affect for 2
hours per year (once they've properly configured their system).
I won't be fixing the 2hr/8766hr = 1/4383 = 0.023% problem until we've
got some of the 100% problems fixed, but maybe that's just me.
Mike