Closed ghost closed 4 years ago
I'll guess I found the error: It's working correct in Python 3 but "wrong" in Python 2.
The directive %z
(small z
) seems to be new for Python 3 and doesn't exist in Python 2.
time.strftime
: Python 3 vs. Python 2
$ python2
Python 2.7.17 (default, Nov 7 2019, 10:07:09)
[GCC 7.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%Y%m%d%H%M%S %z', time.localtime(1586730900))
'20200413003500 +0000'
>>> exit()
$
$
$ python3
Python 3.6.9 (default, Nov 7 2019, 10:44:02)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%Y%m%d%H%M%S %z', time.localtime(1586730900))
'20200413003500 +0200'
>>> exit()
The output from Python 3 is correct and causes correct time in EPG data.
Possible solution: use time.gmtime
for Python 2.
Of course, this will also work for Python 3 but it's more convenient to have local time strings and so time.localtime
is maybe the better solution for Python 3.
P.S.: It's on the actual Linux Mint 19.3 (based on Ubuntu 18.04 Bionic Beaver), where Python 2 is used by default. However, I wonder about the requirements and a successful test with Python 2.7.
That was a tricky one. I spent some time recreating it. Seems in Python 2.7 the issue is that either time.localtime does not pass the timezone properly when using time.strftime with it or time.strftime does not pick it up properly. However, time.strftime('%z') called on its own properly outputs the timezone offset. I used that to create the string properly.
Python 2.7.17 (default, Mar 31 2020, 17:25:23)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%Y%m%d%H%M%S %z', time.localtime(1586730900))
'20200413003500 +0000'
>>> time.strftime('%Y%m%d%H%M%S ', time.localtime(1586730900)) + time.strftime('%z')
'20200413003500 +0200'
>>>
I tested it in 2 Python Docker containers. First one was 2.7-alpine with tzdata installed and TZ ENV set to Europe/Vienna as well as 2.7-buster with the ENV set properly. Both worked. I hope that fixes it for you as well. Feel free to re-open the issue if it still persists. I can take a look at it in a Linux Mint VM to recreate the issue.
It is commited to master now.
It looks also good at my Linux Mint 19! Python 2 and Python 3 brings the same correct result:
$python2
Python 2.7.17 (default, Nov 7 2019, 10:07:09)
[GCC 7.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%Y%m%d%H%M%S ', time.localtime(1586730900)) + time.strftime('%z')
'20200413003500 +0200'
>>> exit()
$
$
$python3
Python 3.6.9 (default, Nov 7 2019, 10:44:02)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%Y%m%d%H%M%S ', time.localtime(1586730900)) + time.strftime('%z')
'20200413003500 +0200'
>>> exit()
Thx!
As I noted in https://github.com/achtnullzwei/A1TV_EPG/issues/12 date/time is wrong.
Example:
The original JSON data:
The correct starting time is 00:35 local time (CEST, UTC+02:00). The given time zone in XML data is "+0000" (UTC) and so the give date/time "20200413003500" is in UTC and therefore it is wrong.
The epoch (Unix) time "1586730900" is Montag, 13. April 2020 00:35:00 in CEST (UTC+02:00) and Sunday, 12. April 2020 22:35:00 in UTC.
A correct value in XML would be either
20200412223500 +0000
or20200413003500 +0200
(if I'm right).See also DTD.
P.S.: I guess it's also possible to fix the time somehow in Tvheadend but this is not a good way (and also daylight saving time has to be handled manually).