[mythtv] Could we use thetvdb for tv preview images?

[Robert Johnston]

On 01/07/2010 10:33 AM, Ed W wrote:
>   On 30/06/2010 09:54, Gavin Hurlbut wrote:
>> On Tue, Jun 29, 2010 at 5:51 PM, Nick Morrott
>> <knowledgejunkie at gmail.com <mailto:knowledgejunkie at gmail.com>> wrote:
>>
>>     Here's an existing ticket if anyone's interested. Beirdo recently
>>     hinted he may look at it in the future.
>>
>>
>> It may take some time before that becomes a priority though. It is a
>> significant amount of work to convert all date/time handling to UNIX
>> epoch time... however, if we did at some point, the removal of many
>> conversions to and from could give us a decent amount of extra CPU
>> cycles, although likely not all that noticable these days with such
>> fast processors. It could also allow us to remove timezone constraints
>> as internally it would all be UTC, essentially, and the only time the
>> timezone really would matter is on output to a human.
>>
>> I have many other things in my queue ahead of considering this massive
>> of a change, so don't hold your breath :)
>>
>
> Is there not already something in QT that can handle this, eg QDateTime?
> There is probably some non zero difficulty to get everything in the DB
> to UTC, but thereafter all date calculations can be done using UTC dates
> and converted only for presentation to the user?

AIUI, currentDateTime uses Localtime by default, but this can be 
overridden by specifying a calling the "toUTC" function:

QDateTime dtmNowInUTC = QDateTime::currentDateTime().toUTC();

Will get the current date and time in UTC. If you replaced every call to 
"currentDateTime()" with "currentDateTime().toUTC()", and converted the 
DB to use UTC, it would probably solve the whole thing in one fell 
swoop). If you want to output something to the screen for display in the 
current local time, you can call 
"dateTime.toLocalTime().toString(whatever)" which will handle the 
conversion for you.

TBH, converting the dates in SQL is actually fairly easy:

UPDATE recordings SET
    starttime = CONVERT_TZ(starttime,'SYSTEM','UTC'),
    endtime = CONVERT_TZ(endtime,'SYSTEM','UTC'),
    progstart = 
IF(ISNULL(progstart),NULL,CONVERT_TZ(progstart,'SYSTEM','UTC')),
    progend = IF(ISNULL(progend),NULL,CONVERT_TZ(progend,'SYSTEM','UTC'))

Would convert the "recordings" table from system time to UTC, though 
this would obviously have to be applied to each other table in turn.

> On the surface it would seem that most of the Myth code wouldn't be
> touched (after all comparing, manipulating dates remains the same, who
> cares what reference point they are based on). The trick would seem to
> be the DB upgrade, ensuring xmltv scrapers convert correctly, EIT input
> is adjusted correctly and basically all the input points to the system?

Given that XMLTV dates are supplied in ISO format (IE, with timezone 
data intact), there is no problem there. EIT data, however, is beyond my 
realms of knowledge, but may be defined in a similar way. If it's not, 
using toUTC() on the existing code would probably be enough to solve it.

> Sounds like a useful change to have on the todo list anyway?

I agree.