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

[Ian C. <ij...@he...>]

On Fri, 2016-12-16 at 20:29 +0000, Mark Perkins wrote:

> Sure,  but i am I intrigued that your listing provider (who was your 
> listing provider?)

It's schedules direct via tv_grab_sd_json. I've CC'd xmltv-devel, just
FtheirI I guess since as I said earlier I don't think 1s here or there
is worth worrying about (but if someone else wants to worry, fine!)

Context for xmltv-devel readers: This thread starts at http://lists.myt
htv.org/pipermail/mythtv-users/2016-December/390066.html and it appears
that something in the SD -> tv_grab_sd_json is mishandling the leap
second i.e. programs crossing midnight this year end 1s early

(independently mythfilldatabase does not accept the actual leap second
as an input, which is what I originally reported, but it seems mostly
moot since it looks like they shouldn't be present in the first place
for the given data).

>  is ending (and maybe starting) programs at 1sec before 
> the hour. Do all your other programs end at xxxxxxxxxx5959 ie the ones not 
> around the end of the year? Or xxxxxxxxxx2959 if ending on the half hour? 
> Just curious.

Most programs span midnight, one of the "bad" ones from my unadjusted
data (so without the sed I mentioned earlier) was:
    <programme start="20161231232500 +0000" stop="20161231235960 +0000" channel="24321">
    <programme start="20170101000000 +0000" stop="20170101001500 +0000" channel="24321">

picking a random other channel at a random other time (not over midnight):
    <programme start="20161223002000 +0000" stop="20161223005000 +0000" channel="25117">
    <programme start="20161223005000 +0000" stop="20161223011500 +0000" channel="25117">

picking another random one with 5959 in it though:
    <programme start="20161231170000 +0000" stop="20161231190000 +0000" channel="31786">
    <programme start="20161231190000 +0000" stop="20170101005959 +0000" channel="31786">
    <programme start="20170101010000 +0000" stop="20170101060000 +0000" channel="31786">
    <programme start="20170101060000 +0000" stop="20170101080000 +0000" channel="31786">

and another:
    <programme start="20161231210000 +0000" stop="20161231230000 +0000" channel="57747">
    <programme start="20161231230000 +0000" stop="20170101005959 +0000" channel="57747">
    <programme start="20170101010000 +0000" stop="20170101030000 +0000" channel="57747">
    <programme start="20170101030000 +0000" stop="20170101060000 +0000" channel="57747">

WRT the half hour and other offsets they have a similar issue when
spanning the leap second e.g.:
    <programme start="20161231210000 +0000" stop="20161231220000 +0000" channel="65161">
    <programme start="20161231220000 +0000" stop="20170101002959 +0000" channel="65161">
    <programme start="20170101003000 +0000" stop="20170101011500 +0000" channel="65161">
or
    <programme start="20161231210000 +0000" stop="20161231233000 +0000" channel="21824">
    <programme start="20161231233000 +0000" stop="20170101001459 +0000" channel="21824">
    <programme start="20170105011500 +0000" stop="20170105030000 +0000" channel="21824">

So it looks like crossing the leap second has introduced a 1s quirk,
but it seems to resolve itself once programs are fully within 2017.

Ian.