No subject

Sun Sep 9 17:16:26 UTC 2012

starttime/endtime be the localversion and then have column specifically for
UTC time, but that would require changing every reference throughout the
code, which might not be ideal.

*** And before you even suggest it, please don't take that as an
invitation/suggestion to remove that interface :-)

Ron Frazier

Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Nov 5, 2012 a=
t 4:36 PM, Michael T. Dean <span dir=3D"ltr">&lt;<a href=3D"mailto:mtdean at t=" target=3D"_blank">mtdean at</a>&gt;</span> w=

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Besides, users have been crying out for us t=
o convert MythTV&#39;s internal time storage to UTC for years, now--all bec=
ause they were upset that a couple times per year they had to think for a c=
ouple seconds to figure out proper start early/end late overrides required =
to make sure that any show that aired on DST changeover would record proper=
ly (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). =A0A=
nd 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&#39;m sure you understa=
nd why it&#39;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 =

We&#39;ve been told by the users that any sane program uses UTC, and that i=
t was a travesty that MythTV didn&#39;t. =A0So, now the users have what the=
y&#39;ve been asking for. =A0I&#39;d hate to think that maybe the users wer=
e demanding something without understanding the consequences...<br>

That said, custom/power recording rules are an advanced feature for advance=
d users. =A0Eventually, we&#39;ll rewrite the entire interface to shield th=
e user from not only the issue of time conversion, but--even worse as far a=
s 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 ge=
ts to the database (i.e. how to write it so that it doesn&#39;t break the /=
extremely/ important scheduler query it gets inserted into).<br>

In the interim, you&#39;ll notice that /all/ of the example clauses show th=
e proper SQL for the conversion, and since &gt;99.9% of users probably neve=
r use power rules for anything that&#39;s not possible with those example c=
lauses, I&#39;d argue that it&#39;s not much more difficult to use than it =
was before the change. =A0And that doesn&#39;t even take into account the f=
act that the vast majority of power recording rules probably shouldn&#39;t =
even be using times (i.e. for the same reason that users should choose &quo=
t;any time&quot; rules over &quot;time slot&quot; rules when scheduling wit=
h the normal interface--because what should matter is that you record the s=
how you want, not what time it was when you recorded it).<br>

mythtv-users mailing list<br>
<a href=3D"mailto:mythtv-users at" target=3D"_blank">mythtv-users at m=</a><br>
<a href=3D"" target=3D"_=
</div></div></blockquote></div><br><br>Mike, <br>The problem is, it shouldn=
&#39;t be an either/or solution. Although the time change recording issue w=
as 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 c=
orrect thing to do, IMHO.<br>
<br>On the other hand, UTC time is the type of thing that should never be e=
xposed to the end user unless they go explicitly digging for it. Thus for t=
hings 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 invi=
tes non-power-users to dig into it***, but it does touch things at a very l=
ow level. <br>
<br>The ideal way to handle it would be to have both sets of times in the d=
atabase (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 additi=
onal columns called startlocaltime (or localstarttiime...not sure which con=
vention looks better) and endlocaltime=A0 would simplify the issue. From a =
user experience standpoint, it might even be better to have starttime/endti=
me be the localversion and then have column specifically for UTC time, but =
that would require changing every reference throughout the code, which migh=
t not be ideal.<br>
<br><br>*** And before you even suggest it, please don&#39;t take that as a=
n invitation/suggestion to remove that interface :-)<br><br>-- <br>Ron Fraz=


More information about the mythtv-users mailing list