Tzahi12345
commented
1 year ago I just tested this in a non-Docker environment and I'm not seeing this behavior.
Everything UI side is assuming your local timezone, and then one of two things happens:
- If one-off, info is converted to a UNIX timestamp (conversion done by browser)
- If recurring, we'll save the hours/minute info which will get consumed by the backend when it schedules the task (conversion done by backend)
What I guess is going on is the backend doesn't know it's in CST (despite you setting the TZ), and assumes it's in GMT-0. I don't have a container handy atm, but can you try one thing:
- Schedule a task, this time don't make it recurring
- See if the time you set is the same as the time you see
- Optionally, schedule the task to run (non-recurring) in a minute or two and see if it actually works
You do have a point though, in that when there's a mismatch in the backend vs. frontend timezone, the frontend one should be used. I updated the WIP PR I have for v4.3.1 to include that, which should solve the issue here: https://github.com/Tzahi12345/YoutubeDL-Material/pull/809/commits/8c63a78884da5c53b7707713f7fe08be9778d659
Describe the bug
When scheduling maintenance task (update yt-dlp) to run daily at 12:30am, the scheduled task appears to be setting at GMT time without TZData offset.
To Reproduce Steps to reproduce the behavior:
Expected behavior Should not perform TZ adjustment on scheduled task time (or there is a display inconsistency)
Screenshots If applicable, add screenshots to help explain your problem.
Environment installed version: v4.3 Installation type: docker Docker tag: nightly Commit hash: 9c0a77c Build date: 2022-12-27
Additional context Running via TrueNas Scale/Docker-Compose (TrueCharts) Container TZ set to America/Chicago (GMT -6).