Open cr04ch opened 11 months ago
jtojnar
commented
11 months ago I wonder how common the future dates are outside of incorrectly set up server timezones. I would not want to hide items just for that reason.
Maybe when we have per-feed configs, we could allow it. It might be useful for stuff like YouTube premieres, if they use future dates.
One thing that then becomes unclear is how to order the items. With the current implementation, they would remain pinned to the top.
cr04ch
commented
11 months ago I agree that this is uncommon, but as it happened by accident, I read the specification. Since the specification does not say that such data is invalid, it could theoretically occur in practice. I just think that it may not be the right way to change a valid data for practical reasons.
I think the current implementation would be sufficient for the ordering.
PhrozenByte
commented
7 months ago The RSS feed of ZDF Mediathek, the media library of a German public service broadcaster, does that - i.e. they create entries for shows that weren't aired yet and are thus totally worthless, sometimes weeks in advance. That's super annoying. I've created a ZDF Mediathek spout about 6 years ago (see #885) that filters future entries, but the spout was rejected due to it being rather uncommon. I recently saw that Selfoss now also supports filters, so I think that a distinct spout isn't really necessary anymore, but just a new filter. What do you think @jtojnar? I could look into the filters code and possibly write a new filter for that.
jtojnar
commented
7 months ago Representing this as a filter would be ideal. Unfortunately, the filters are currently limited to a single filter so it would not be possible to combine it with another filter. But maybe it would still be good enough for most people.
Also, in many feeds, the timezone is incorrect so we would need to account for that. Maybe separate timezone correction field would be cleanest.
What happens if the publication date of an item is in the future? As far as I can see, currently selfoss replaces such dates with the feed download date.
The RSS 2.0 Specification says:
Therefore, I don't think it's a good solution to replace the otherwise valid date value, instead either hide such items as long as the date value is for the future, or (I think this is the better solution) store and display the original date value.
The second solution introduces an additional problem: currently, if a date is future, the calculation or display of the relative time is incorrect, because it displays the same as if the time was X minutes ago.
(As selfoss replaces future dates, this should not happen at the moment, but while testing the #1447, I had a date pointing into the future because of an incorrectly recorded date in the database.)