Write full upload timestamp instead of date-only so Plex doesn't shift dates by one day

[Sissing]

Summary

Youtarr writes the release date as a date-only string (YYYY-MM-DD). Plex interprets a date-only value as local midnight, converts it to UTC for storage, and in any timezone ahead of UTC the stored value lands on the previous day. Clients rendering the raw UTC date then show the video one day early.

Everything Youtarr writes is correct. This is Plex's interpretation of an ambiguous value. But Youtarr already has the exact upload time available and could remove the ambiguity.

Evidence

For a video uploaded 2026-08-03 17:11 UTC:

Source	Value
Filename (Plex TV Series preset)	S2026E08031711 → 2026-08-03 17:11
.nfo <premiered>	2026-08-03
Embedded MP4 --year tag	2026-08-03
Plex stores	2026-08-02 22:00:00 UTC

22:00 UTC is exactly midnight in Europe/Amsterdam (UTC+2). Across an 18-video library, 17 are stored at exactly 22:00:00 UTC, and that uniformity indicates a date-only value being parsed as local midnight rather than per-video data.

For contrast, on the same Plex server: a library whose agent supplies real timestamps stores 00:00:00 UTC for all 1252 episodes, and a Personal Media library that sources dates from file mtime shows scattered times. Only the date-only path produces the uniform one-day offset.

Cause

server/modules/videoDownloadPostProcessFiles.js:515-520 builds the value from upload_date (YYYYMMDD), discarding any time component:

if (jsonData.upload_date) {
  const year = jsonData.upload_date.substring(0, 4);
  const month = jsonData.upload_date.substring(4, 6);
  const day = jsonData.upload_date.substring(6, 8);
  const releaseDate = `${year}-${month}-${day}`;
  apArgs.push('--year', `${releaseDate}`);

Suggested fix

The same .info.json already contains timestamp, a Unix epoch including the time. The Plex TV Series filename preset already relies on it (client/src/utils/filenameTemplate/presets.ts:27):

%(timestamp>S%YE%m%d%H%M)s %(title).64B

So the data is present at the point where the tag is written. Emitting a full ISO-8601 UTC timestamp when timestamp is available would give Plex an unambiguous instant:

if (jsonData.timestamp) {
  apArgs.push('--year', new Date(jsonData.timestamp * 1000).toISOString());
} else if (jsonData.upload_date) {
  // existing date-only fallback
}

I verified that AtomicParsley accepts a full ISO-8601 value and stores it verbatim:

$ AtomicParsley video.mp4 --year "2026-08-03T17:11:00Z" --overWrite
$ ffprobe -show_entries format_tags=date video.mp4
TAG:date=2026-08-03T17:11:00Z

I have not verified end-to-end that Plex then stores the corrected day, which needs a re-download plus a library refresh, which I have not run. So the AtomicParsley half is confirmed; the Plex half is the reasonable expectation that an unambiguous instant is not reinterpreted as local midnight.

The <premiered> field in the .nfo may deserve the same treatment, although NFO consumers generally expect a date-only value there, so that part is less clear-cut.

Impact

Affects users in timezones ahead of UTC: Europe, Africa, Asia, Oceania. Timezones behind UTC are unaffected, because local midnight converts to a later UTC time on the same calendar day, which may be why this has not surfaced more often.

Environment

• Youtarr 1.82.1 (Docker, dialmaster/youtarr:v1.82.1), yt-dlp 2026.08.19
• Plex Media Server 1.43.4, TV Shows library, Personal Media Shows agent
• Host timezone Europe/Amsterdam (UTC+2)

[Sissing]

Follow-up: this is Plex agent specific.

• com.plexapp.agents.none (legacy, shown as Personal Media / Personal Media Shows): parses date-only values as local midnight, so in timezones ahead of UTC the stored date lands one day early. All observations above came from this agent.
• tv.plex.agents.none (newer): same files, same date-only tags, stored at 00:00:00 UTC on the correct day.

Youtarr's output is identical in both cases, and only the reading agent differed. So the original framing is wrong and no date fix is needed.

The remaining request is minor: Plex discards the time of day, so writing a full ISO-8601 timestamp would preserve it. Fine to close if that's not of interest.