Open qsirod opened 3 months ago
Yes, there is a bug that puts the wrong name in the crid! Thanks for creating this issue so i don't forget to fix it.
I'll have to dig into cridlib (which does a bunch of unholy timezone fuckery) to get this fixed.
As an aside, the timestamp in the crid is UTC, so it's always right... More details on the RaBe CRIDs may be found here btw.
i tried fixing forward in https://github.com/radiorabe/python-rabe-cridlib/pull/328 and added some test code to https://github.com/radiorabe/python-rabe-cridlib/issues/244
so far this is motivating me to take more time to get at the root of the tz issues underlying this problem.
there is a huge amount of custom timezone conversion going on in the code base, both from external inputs that follow some non (our) standard conventions as well as from internal components.
i also want to update the tests in this (and the CRIDlib) repo to run in TZ=Europe/Zurich
as well as UTC
. somehow the test code isn't as tz aware as i assumed.
According to archiv.rabe.ch, the schedule for January 17th 2024 was:
According to the list of songs sent to SUISA for January 2024, the generated CRIDs contain program names that do not match the schedule:
It seems the program names in the CRID fields are shifted by an hour (the program SPAZZ-TIME KONTINUUM ran the day before until midnight). Possibly due to daylight savings time.
This leads to the CRIDs often containing a wrong program name.