Open tonycpsu opened 1 month ago
Downgrading to 3.9.2 seems to fix this, FWIW.
Thank you, we thought we had made sure that no default date of 0 (milliseconds after 1.1.1970 00:00 UTC) can appear anywhere. Can you tell us the feed source as well? Then we can make sure that we refine the feature to avoid that behavior. Can you add the column for creation date and see what that shows in cases when updated date is 0?
Feed source is Inoreader -- it seems to affect all of my feeds, not a single RSS source.
Here's what it looks like with 3.9.3 release with published date visible.
Another anomaly here: Date published is later than last update This is the Github feed for recent commits to vienna´s master branch (an atom feed)
I was not able to find the source of such anomalies. According to the current code, if the feed source does not contain the last update, it is set to the publication date if that exists, or to the date when the article was received. For the publication date, if the feed does not contain it, the updated date (if it exists) or the current date is used, whatever is earlier.
@barijaona, @josh64x2 or @Eitot, maybe you can find a reason for the observed anomalies.
I am not sure about my anomaly, it could have been caused by using a development version of Vienna. @tonycpsu did you use any beta version?
Not sure if it's related but using Version 3.9.3 :fd467d52: (8375)
I get the date "01-01-1970, 01:00" for both published as updated dates. The source of the feed seems correct?
I think this only happens after a refresh when an article was already there and is updated?
Not sure if it's related
It certainly is.
I get the date "01-01-1970, 01:00" for both published as updated dates. The source of the feed seems correct?
Looks like the source is correct, have to look up whether "pubDate" is taken into account though. The date is the same as in the other cases, "0" but in your time zone.
I think this only happens after a refresh when an article was already there and is updated?
That's a good hint and in my case, I had the same gut feeling but couldn't find the code causing that. I will try another time this weekend.
I just realized that the RefreshManager is also manipulating the article dates, which may be causing effects that I have not considered so far.
Hi TAKeanice,
Just to inform you: with Version 3.9.4 :498937af: (8382)
I'm still getting reset dates...
From some WordPress blogs I'm following and eg. the example below from which I know it's an updated article.
Hi @joostdekeijzer , thank you for adding that example. I suspect the RefreshManager, which I didn't fix in the last update, is the culprit. I hope to find some time this weekend to figure it out and create a fix.
I just subscribed to https://exiftool.org/rss.xml and I do not reproduce the issue…
I just subscribed to https://exiftool.org/rss.xml and I do not reproduce the issue…
The issue occurs when an article in the feed is updated by that site. That does not happen very often (and ExifTool is not a very busy feed anyway).
Some other feed I get the 1970 issue with just now (after refresh of article) is https://feeds.feedburner.com/9To5Mac-MacAllDay .
Describe the bug Since the most recent update, some of my articles are showing dummy date of 12/31/1969 in "Last Update" column.
To Reproduce Not sure what caused it, but it seemed to appear around when I upgraded to
Version 3.9.3 :fd467d52: (8375)
I use Inoreader as my feed backend, if that is relevant.
Screenshots
Please complete the following information:
Version 3.9.3 :fd467d52: (8375)
14.1.1 (23B81)
Additional information: