[mythtv-users] MythTV does not handle daylight savings properly
ron at ronfrazier.net
Wed Nov 7 17:52:06 UTC 2012
On Mon, Nov 5, 2012 at 4:36 PM, Michael T. Dean <mtdean at thirdcontact.com>wrote:
> Besides, users have been crying out for us to convert MythTV's internal
> time storage to UTC for years, now--all because they were upset that a
> couple times per year they had to think for a couple seconds to figure out
> proper start early/end late overrides required to make sure that any show
> that aired on DST changeover would record properly (and, perhaps, to save
> them running a lossless transcode to cut off the extra time they put in to
> those DST-changeover recordings for safety). And since we all know just
> how many good shows are on at 2:00am, especially on the 2 days of the year
> that DST changes occur, I'm sure you understand why it's a good idea to
> give up ease-of-use on 99.98% of the year so that people can record their
> late-night infomercials easily on that other 0.02%.
> We've been told by the users that any sane program uses UTC, and that it
> was a travesty that MythTV didn't. So, now the users have what they've
> been asking for. I'd hate to think that maybe the users were demanding
> something without understanding the consequences...
> That said, custom/power recording rules are an advanced feature for
> advanced users. Eventually, we'll rewrite the entire interface to shield
> the user from not only the issue of time conversion, but--even worse as far
> as user-friendliness goes--from having to know a) SQL, b) the MythTV
> schema, c) the MythTV data constraints, d) exactly how the fragment they
> create gets to the database (i.e. how to write it so that it doesn't break
> the /extremely/ important scheduler query it gets inserted into).
> In the interim, you'll notice that /all/ of the example clauses show the
> proper SQL for the conversion, and since >99.9% of users probably never use
> power rules for anything that's not possible with those example clauses,
> I'd argue that it's not much more difficult to use than it was before the
> change. And that doesn't even take into account the fact that the vast
> majority of power recording rules probably shouldn't even be using times
> (i.e. for the same reason that users should choose "any time" rules over
> "time slot" rules when scheduling with the normal interface--because what
> should matter is that you record the show you want, not what time it was
> when you recorded it).
> mythtv-users mailing list
> mythtv-users at mythtv.org
The problem is, it shouldn't be an either/or solution. Although the time
change recording issue was indeed quite small, it was something that should
never occur if we want myth to be a robust DVR. So storing things in UTC
time was absolutely the correct thing to do, IMHO.
On the other hand, UTC time is the type of thing that should never be
exposed to the end user unless they go explicitly digging for it. Thus for
things the user interacts with, it should always be localtime. Normally the
GUI handles all of that for you, but with power recording rules you end up
in a sort of grey area. We provide a nice gui interface and rule templates
for the not-so-sophisticated user to create these rules, so it sort of
invites non-power-users to dig into it***, but it does touch things at a
very low level.
The ideal way to handle it would be to have both sets of times in the
database (you could do them as calculated columns at query time, but having
the slight increase in database size would be preferable to the performance
overhead of having to calculate these fields dynamically). Having 2
additional columns called startlocaltime (or localstarttiime...not sure
which convention looks better) and endlocaltime would simplify the issue.
More information about the mythtv-users