[mythtv] [mythtv-commits] Ticket #11197: Fix event times in MythZoneMinder broken by the UTC changes

Paul Harrison mythtv at sky.com
Mon Oct 29 23:34:27 UTC 2012


On 29/10/12 14:11, MythTV wrote:
> #11197: Fix event times in MythZoneMinder broken by the UTC changes
> -------------------------------------+-----------------------------
>   Reporter:  mythtv@…                 |          Owner:  danielk
>       Type:  Patch - Bug Fix          |         Status:  accepted
>   Priority:  minor                    |      Milestone:  0.26.1
> Component:  Plugin - MythZoneminder  |        Version:  Master Head
>   Severity:  medium                   |     Resolution:
>   Keywords:                           |  Ticket locked:  0
> -------------------------------------+-----------------------------
>
> Comment (by danielk):
>
>   paulh, the standard is now for all dates to be UTC unless there is a good
>   reason for them not to be. This means we don't need to be checking what
>   timezone a date time is in, if the variable name contains "localTime" it
>   is local time, otherwise it is not. If there is a real performance problem
>   we can of course rename the variable and use local time internally. Is it
>   20k event per second, per hour, per day?
These are ZoneMinder events which are what ZM calls its recordings so 
20k would probably be from a month or more. If I was converting the 
events screen to MythUI now I would use the new itemVisible signal of 
the buttonlist and only update the text and image for the visible items 
similar to what I did in MythMusic.

>   BTW We're ironically doing a lot fewer utc<->localtime conversions overall
>   now. We used to be doing a few hundred conversions per second in the
>   frontend because QDateTime::currentDateTime() uses it. Now with
>   QDateTime::currentDateTimeUtc() we avoid converting to local time most of
>   the time and it has a measurable positive effect on both CPU usage and
>   responsiveness.
>
That's good to hear but I think you are talking about something 
completely different from the problem here. AFAIK the times here are 
always in local time that is how ZM stores them in it's database so 
converting them to UTC and then back again to display them seems a 
little pointless in this case.

Paul H.



More information about the mythtv-dev mailing list