-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future pubDates #58
Comments
There should be a recommended behavior for clients dealing with items that have a |
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 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 |
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. |
No description provided.
The text was updated successfully, but these errors were encountered: