Closed minusf closed 3 weeks ago
I acknowledge the problem.
RSS specifications do not differentiate between publication date and modification/update date.
Atom and JSON Feed specifications have the distinction, but Vienna's architecture hasn't changed to handle the distinction. Vienna just takes the most recent date, which is likely to be the <updated>
date.
I am undecided on what to do: is the distinction important enough to justify an increase of database size?
I think one additional date value can't hurt any proper database
I think it makes sense to have both fields.
Some creators go back and keep changing their content. It is debatable if this should result in bumping the content to the front again, but for exactly this reason if the RSS feed provides the distinction, the app should too...
I think one additional date value can't hurt any proper database
It's not just an additional field in the database, I am also thinking about how this should affect the user interface.
In fact, since 2006 😱 (commit ad60f21 for version 2.1.0), the messages
table includes a createddate
field, but this is barely used and its only impact for end users is the existence of the "Last Refresh" filter.
Let's take an analogy : since OS X, Apple's filesystem handles multiple dates for files : creation date, date added, last modification date, last access date… However, for a long time, Apple's Finder only displayed the 'last modification' date. As far as I remember, display of the other dates or use of them for sorting has been added relatively recently and these features are only discreetly put forth in the user interface.
In my opinion, Vienna's philosophy is similar to Apple's one : hide complexity as much as possible. I am therefore tempted to add a "sort by created date" option, but continue to display only the "last update date" in the article list. Apart from the "keep it simple and stupid" philosophy, there are other reasons behind this:
I am concerned that users might not understand what "created date" means in this context (maybe "date added" or "date fetched" instead?) and that they cannot see that date anywhere. What would be the harm of adding another column that is not visible by default?
Maybe Vienna should be clearer about which date it shows, e.g. by changing the label from simply "date" to "date published/modified"?
Closed in 3.9.4
Describe the bug
updated
dates taking precendence overpublished
even when setting is turned offTo Reproduce
Mark updated articles as new
setting turned off, set order by date descdencingScreenshots
xml to test: https://www.youtube.com/feeds/videos.xml?playlist_id=UULF21uZkfXpT8rPY-gPgMiCwA
Please complete the following information:
Additional information: In which version of Vienna does the problem not occur, if applicable.