Skip to content
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

Open
farski opened this issue Feb 1, 2017 · 7 comments
Open

Future pubDates #58

farski opened this issue Feb 1, 2017 · 7 comments
Labels

Comments

@farski
Copy link
Member

farski commented Feb 1, 2017

No description provided.

@farski
Copy link
Member Author

farski commented Feb 1, 2017

There should be a recommended behavior for clients dealing with items that have apubDate in the future.

@farski farski added the idea label Feb 1, 2017
@kookster
Copy link

kookster commented Feb 1, 2017

This seems like an error condition to me, but I understand it is used as a hack for itunes positioning.

@GluedToTheScreen
Copy link

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?

screenshot_db_futuredates

@rustyshelf
Copy link

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.

@ziggythehamster
Copy link

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.

@rustyshelf
Copy link

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.

@ziggythehamster
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants