[mythtv-users] mythfilldatabase: Ignoring unknown timestamp format: 20161231235960

Mike Hodson mystica at gmail.com
Sat Dec 17 22:35:51 UTC 2016


On Sat, Dec 17, 2016 at 3:12 PM, Gary Buhrmaster <gary.buhrmaster at gmail.com>
wrote:


> And, technically, programs can end on the 60th
> second of December 31st.  That MythTV does
> not handle a valid time (due to the QDateTime
> implementation) should likely have a ticket created,
> and marked as closed "wont fix" (or "upstream")
> to document the issue for future generations so
> that when it hits again (and it will always hit again,
> perhaps in some other context) one can point
> to the ticket.


Hi Gary,

I personally have a differing opinion in this case.

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.

Knowing that leap seconds have occurred since 1972, this is a particularly
bothersome limitation in a truly cross-platform toolkit.
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.

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.

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?

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.

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.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20161217/0215a1b1/attachment.html>


More information about the mythtv-users mailing list