From 94faf5b37624b228629d2487dcb3c14483562cd7 Mon Sep 17 00:00:00 2001 From: garret Date: Fri, 13 Oct 2023 12:25:59 +0100 Subject: ShareTime: handle day out of range for month MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit the site will accept this so we have to as well i should probably try and handle this in SiteTime but cant be fucked right now iirc the site just blanks out if the day is out of range so the datetime exception matches the site's behaviour 👍 --- yt_dlp_plugins/extractor/radiko_time.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) (limited to 'yt_dlp_plugins/extractor/radiko_time.py') diff --git a/yt_dlp_plugins/extractor/radiko_time.py b/yt_dlp_plugins/extractor/radiko_time.py index c67f644..981a966 100755 --- a/yt_dlp_plugins/extractor/radiko_time.py +++ b/yt_dlp_plugins/extractor/radiko_time.py @@ -113,11 +113,17 @@ class RadikoShareTime(RadikoTime): days_to_add = hour // 24 hour = hour % 24 - # XXX: doesnt handle day invalid for month (the site actually works with this) + days_to_add += max(0, day - 28) + day = min(day, 28) + + # site won't handle month out of range (eg 2023-13-05), thank fuck self.datetime = datetime.datetime(year, month, day, hour, minute, second, tzinfo = JST) self.datetime += datetime.timedelta(days=days_to_add) if __name__ == "__main__": - assert RadikoShareTime('20230630296200').timestring() == '20230701060200' - assert RadikoShareTime('20230630235960').timestring() == '20230701000000' + assert RadikoShareTime('20230630296200').timestring() == '20230701060200' # 30-hour + >59 minutes + assert RadikoShareTime('20230630235960').timestring() == '20230701000000' # month boundary + assert RadikoShareTime('20240229010000').timestring() == '20240229010000' # feb 29th in leap year + assert RadikoShareTime('20230229010000').timestring() == '20230301010000' # feb 29th in not-leap year + assert RadikoShareTime('20230823180000').timestring() == '20230823180000' # normal -- cgit v1.2.3-70-g09d2