[mythtv-users] Myth can't handle daylight time saving?

[f-myth-users at media.mit.edu]

    > Date: Sun, 25 Oct 2009 08:30:45 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > On 10/25/2009 06:18 AM, raptor jr wrote:
    > > this only happends 2 times a year, but still, those two times could be 
    > > frustrating.

    > (but only to people who want to record something in the 2-hrs of 
    > ambiguous time which, in the US, is at a time when virtually nothing 
    > interesting is on)

Sez you. :)

(Personally, I've been screwed every single transition---7 or 8 in all
so far---by something that either (a) aired once and never again or
(b) was the last airing of something that aired multiple times, but
Myth tried to record in that slot because it thought it could, e.g.,
because it recorded something else during an earlier airing.
Remarkably, this upcoming transition is the first time I recall that
my Myth isn't actually trying to record anything---but some of the
other entries between 4-6am look a little fishy, durationwise, and
I'll have to investigate if that's a symptom of the issue where the
transition is at 0200/0300 but some/all? broadcasters define their
day as starting at 0600.)

Note that there are two distinct ways to be screwed:
(a) Myth gets correct data (whatever that means) but does the wrong
    thing.  (Very definitely seen this; details on request.)
(b) Myth gets wrong data (SD or broadcaster screwed up about what was
    on when).  Also seen this [possibly also years ago on my TiVo];
    can't do much about it; -maybe- there might be some way to warn
    if things look odd, but I'm dubious.

    > > Should i have done it some other way to avoid this problem?

    > Myth stores all recording times in the database in local time.

    > http://svn.mythtv.org/trac/ticket/5853

I'd given up on ever getting this fixed until this ticket got opened
and stayed opened---in particular, the statement that, in principle,
storing all data in UTC and converting to localtime when necessary
was acceptable, which is the only way anyone ever solves this problem
for real.  Until that statement, I thought it was going to be an
uphill battle just to get that approved.

I'm creeping up on having a devo system set up that will run trunk;
fixing DST handling is likely to be something I take a shot at, though
I would be overjoyed if someone else beat me to it.  If anyone has
advice on potential pitfalls (technical and usability), I'm all ears;
I may start another thread at the time I try to start the work to
collect those thoughts.

    > Do you still have the backend logs from the time?

It might actually be useful to ask several people around the world
(both US Schedules Direct people and at least one from each of several
other countries) to SAVE YOUR DATA around a DST cutover (in either
direction) so we've got something that can be used as test cases.
[I presume attaching it to the ticket would be the way to go, and
maybe I should mention it in its own thread soon (before it's gone)
so people who've stopped reading far into this one might be able to
help.]

I'm assuming that what we should save should be the XML produced by a
grabber, and that it would probably be useful to have as big a subset
of these choices as possible:
(a) a grab from a day (or more) before a transition
(b) a grab after midnight but before the transition
(c) a grab after the transition but on the same day
(d) a grab the day after the transition

It's not likely (c) or (d) will expose any bugs, but it'd be nice to
be able to check.

[Some idea of the ground truth, e.g., "did the data reflect reality?"
would also be handy but may be much harder to obtain.  Also not included
in my thinking at all 'cause I'm in the US:  EIT.]

(I've already been saving my Schedules Direct data, so I think I've
got that covered, though I don't have have all the possibilities
above and so it wouldn't hurt for someone else to give it a shot---
I may arrange to run my grabber specially this weekend to cover
them all, since I think I'd only have to do (b) anyway.  But the
international data would no doubt be useful too.)