[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