<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 17, 2016 at 3:12 PM, Gary Buhrmaster <span dir="ltr"><<a href="mailto:gary.buhrmaster@gmail.com" target="_blank">gary.buhrmaster@gmail.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And, technically, programs can end on the 60th<br>
second of December 31st.  That MythTV does<br>
not handle a valid time (due to the QDateTime<br>
implementation) should likely have a ticket created,<br>
and marked as closed "wont fix" (or "upstream")<br>
to document the issue for future generations so<br>
that when it hits again (and it will always hit again,<br>
perhaps in some other context) one can point<br>
to the ticket. </blockquote><div><br></div><div>Hi Gary,</div><div><br></div><div>I personally have a differing opinion in this case.</div><div><br></div><div>It would appear that QT do not, and (likely without a lot of reworking) will not soon attempt to support leap seconds as part of qdatetime. </div><div><br></div><div>Knowing that leap seconds have occurred since 1972, this is a particularly bothersome limitation in a truly cross-platform toolkit. </div><div>However, I also consider that about 99% of the worlds population who uses QT based apps will neither care about a 1 second discrepancy in some sort of logfile, or use a QT app without any bearing on time whatsoever. </div><div><br></div><div>However, we have a nice little corner case.  Not really even an edge case - I fully submit that mythtv is over there in the dusty old corner of 'we really want to work properly but can't due to circumstances out of our control' .  This doesn't sit well with me, a true believer in Postel's Law:  be conservative in what you do, be liberal in what you accept from others. </div><div><br></div><div>If we know there is a problem affecting leap-seconds, that this problem uniquely affects MythTV, and is propagated by very common scheduling software, should MythTV not work themselves out of the corner and develop the corner-fix for this particularly stupid (and pushed upstream to deaf ears) bug?</div><div><br></div><div>MythTV should liberally attempt to catch a datetime error, validate if 'seconds=60' (starting at 0 thus index position 61) and then rework the time to be 1 second different, potentially truncating the recording by one paltry second.</div><div><br></div><div>If this bug still exists by the time the next leap-second is agreed upon by the IERS, I will personally fault anyone who reasonably knows C++ and can contribute to this project who hasn't attempted to patch this at the point of currently-known pain: inside MythTV itself.</div><div><br></div><div>Mike</div><div><br></div></div></div></div>