Future pubDates
farski opened this issue · comments
There should be a recommended behavior for clients dealing with items that have apubDate in the future.
This seems like an error condition to me, but I understand it is used as a hack for itunes positioning.
Gaming dates is a fact. Getting the date value wrong can happen to anyone from time to time... but there are REGULAR "offenders"... hey, there's no rule or enforcement, right? It's the interwebs!!
Anyway, SOME release episodes a short time into the future and others put them YEEEAAARRSSS out there. Maybe the short time issue is the publishing side releasing eps early... is this the behavior you reference?... but others are unquestionably trying to position on date.
When presenting search results or new releases, my web app (which is a downstream RSS presentation client) simply IGNORES any episodes dated in the future. They are filtered
until their time has come. Which, for some, will not happen in my lifetime.
Or maybe create a QUIRK view and show ONLY the future eps?
The pragmatic approach might be to not allow a published date to be newer than the time the entry was created in whatever system you use. This obviously only works for systems that cache data locally or on a server, but that's most podcasting apps. So if an episode has a published date of the 1st of January 2025 at 10am and our system added it on the 2nd of November 2017 at 5pm, then the published date shown to users (and used for sorting, etc) becomes the 2nd of November 2017 5pm.
iTunes has <itunes:order>, so I would just say a pubDate in the future is a validation error. I'm not sure what the behavior should be for a validation error - if clients are doing validation, should they reject an <item/> that fails validation? If they aren't doing validation, then they can ignore the problem. That's a different discussion item.
Unless you're the only game in town telling podcast authors "Hey your new episode isn't there because technically your feed is invalid" is not going to get you very far. I prefer to err on the side of pragmatism where possible.
IMO, feed validators should consider it an error but clients should silently ignore the problem and include any episode with any pubDate.
That said, if people are using pubDate as a way to set an episode to be high priority, maybe that's the problem that needs to be solved.
Since we don't control the clocks on client devices, expecting them to decide if an episode should appear or not seems like it will create more problems than it solves.