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

updated dates taking precendence over published even when setting is turned off #1749

Open
minusf opened this issue May 6, 2024 · 6 comments
Labels
discussion 💬 The issue is or needs further discussion.

Comments

@minusf
Copy link

minusf commented May 6, 2024

Describe the bug
updated dates taking precendence over published even when setting is turned off

To Reproduce

  1. Mark updated articles as new setting turned off, set order by date descdencing
  2. get a youtube feed
  3. get updated content sorted in front of later published content.

Screenshots

xml to test: https://www.youtube.com/feeds/videos.xml?playlist_id=UULF21uZkfXpT8rPY-gPgMiCwA

Screenshot 2024-05-06 at 17 40 44

Please complete the following information:

  • Vienna version 3.9.0 :7ad9df044: (8175)
  • OS version: 14.4.1

Additional information:
In which version of Vienna does the problem not occur, if applicable.

@barijaona
Copy link
Member

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?

@barijaona barijaona added the discussion 💬 The issue is or needs further discussion. label Jun 22, 2024
@TAKeanice
Copy link
Contributor

I think one additional date value can't hurt any proper database

@Eitot
Copy link
Contributor

Eitot commented Jun 24, 2024

I think it makes sense to have both fields.

@minusf
Copy link
Author

minusf commented Jun 26, 2024

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...

@barijaona
Copy link
Member

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:

  • the specifications for some kind of feeds do not distinguish between creation date / last update date
  • article list with vertical layout risks being overcrowded

@Eitot
Copy link
Contributor

Eitot commented Jun 30, 2024

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"?

barijaona added a commit to Eitot/Vienna that referenced this issue Aug 25, 2024
Only when there is a provided publication date on creation, use that one
without questioning it
Fix publication date not being transmitted by RefreshManager.m

Most dates interpretations/manipulations are now in Database.m
During fetching from feeds, we just retrieve the infos and store them in
relevant Article fields.
This makes the logic more apprehensible and easier to maintain.

Solves issue ViennaRSS#1749

Co-authored-by: Barijaona Ramaholimihaso <[email protected]>
barijaona added a commit to Eitot/Vienna that referenced this issue Aug 26, 2024
Only when there is a provided publication date on creation, use that one
without questioning it
Fix publication date not being transmitted by RefreshManager.m

Most dates interpretations/manipulations are now in Database.m
During fetching from feeds, we just retrieve the infos and store them in
relevant Article fields.
This makes the logic more apprehensible and easier to maintain.

Solves issue ViennaRSS#1749

Co-authored-by: Barijaona Ramaholimihaso <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion 💬 The issue is or needs further discussion.
Projects
None yet
Development

No branches or pull requests

4 participants