Feature request: option to specify the timezone of upload date

[zmwangx]

Several options in youtube-dl pertain to upload dates: --date, --datebefore, --dateafter, and --output (the %(upload_date)s template). I didn't inspect the source, but I have the impression that the upload dates are calculated either in UTC or the user's local timezone, and there seems to be no way to change the behavior (actually I tried to inspect the source, but it seems that I need to dig through multiple files, so I gave up). However, sometimes it makes more sense to calculate the upload date in another timezone, e.g., the uploader's timezone. (Of course, youtube-dl usually has no way to tell the uploader's timezone, but the user might know.)

Therefore, I propose a --timezone OFFSET option to modify upload dates, and this option would affect the aforementioned options --date, --datebefore, --dateafter, and %(upload_date)s. For instance, --timezone -8 would calculate the upload date in UTC-8:00.

I'm not sure if this will lead to an overhaul to youtube-dl's existing datetime system, but this option is at least possible with YouTube in theory, since YouTube videos' publishedAt property YYYY-MM-DDThh:mm:ss.sZ includes timezone information.

Use case

Here's an example use case. I usually name my downloaded YouTube videos as such: %(upload_date)s__%(title)s__%(id)s.%(ext)s, and I prefer to have %(upload_date)s in the uploader's timezone, provided that I already have that knowledge. Note that post-processing is hard: say the uploader is in UTC+9:00 and I'm in UTC-8:00, then sometimes the uploader is ahead of me by one day and sometimes not, and there's no way to tell just from a YYYYMMDD date. I can hack up a post-processor based on the video ID, but querying the API again is wasteful if youtube-dl can get it right for the first time. (Moreover, I certainly don't want to write a separate post-processor for each service that I download from.)

[FelixChery]

Did you get a solution to this? I am facing the exact problem.

[zmwangx]

@FelixChery Not really, I closed the issue since apparently no one’s gonna give this any attention amidst the thousands of open issues. Unfortunately it’s something I couldn’t bother to implement myself, so can’t blame others for the lack of enthusiasm.