Hello,
I’ve noticed that if I import a feed from an RSS 2.0 source, the <pubDate> tag gets properly used when sorting by date in the UI.
If I import a feed from an Atom source, the <published> tag is not properly used when sorting by date in the UI. Instead it seems to use the date from the %lt;updated> tag.
This seems intentional classes/feeditem/atom.php#L19. Is there any specific reason for this? Seems like it would be better to prioritize the <published> date.
Waterbottle
Here you go:
https://tools.ietf.org/html/rfc4287
Based on what I’m reading, it seems like updated is the more accurate tag for TT-RSS to use.
Could you quote the specific statement you’re referencing? I can’t seem to find anything that says <updated> is more appropriate to use for UI date sorting.
we update article in the database if needed, why show original date instead of the updated one?
In my case, I’m following youtube RSS feeds and every time a comment is made it updates the <updated> timestamp. This results in a misleading ordering.
I would expect that generally articles are rarely updated, so my thinking was that using <published> instead for date sorting would generally be a welcome change. Though you may have fair objections to that, and I would defer to you. I’m imagining a UI where <published> is used as the date used for sorting, and <updated> is used as metadata in the UI, e.g. last updated 5 hours ago. In any case thank you for your consideration.
by default, tt-rss sorts by batch date then by whatever is specified in the feed. batch date is immutable and is assigned when article is encountered first, so “updated” or any other field is largely cosmetic unless you’re using “newest first” which sorts by feed date, where using updated makes sense because whatever is updated is actually newest.
e: i feel like i repeat myself too much over this stuff. maybe i should start probating people into next century if they just refuse to search for my multiple previous explanations on that matter. alternatively, maybe we should document this somewhere because sorting seems like a recurring question.
e2: internally, newest first is called feed_dates if that makes more sense.
Funny enough… When I read your reply I thought: We should just copy/paste all the times fox writes this and post it on the wiki.
if you could make a faq entry or something with a few links and a short “tl;dr” i would really appreciate it 
I can… but I need to do that tomorrow (later today?)… it’s the middle of the night where I am and I’m practically falling asleep at the moment.
sure, go to sleep instead of wasting time here!
I am indeed only using newest first. The “default” sorting method is too opaque, newest first is better because it’s nice to understand exactly how items are being sorted. FAQ entry would be good to keep news on this up to date. The previous posts I’ve seen on this topic weren’t clear on whether the bad sorting was intentional or buggy or user error.
I just privately patched atom.php. Now sorting is consistent across my atom and rss2 feeds. Ideally the database would store three dates for each item: imported, published, and last updated, that way you wouldn’t have to overload the meaning of “date” in the database.
seems self-inflicted then
it’s pretty much score → batch date → updated, not sure what’s opaque about it
you need to understand that default should work for the majority of feeds, some of which have arbitrarily broken timestamps or no timestamps at all, batch date is a necessary safeguard which also serves in place of original published date which is guaranteed sane
i don’t see any point in storing published while batch date exists. it doesn’t matter for default order where batch date serves as a substitute and it’s useless with newest first, the way i think it should work (as explained above)
Inflicted is good in this case because default sorting was worse. I don’t want to sort by score or batch date. Editing atom.php to be consistent with rss.php fixes this problem for me.
It’s opaque because it’s not clear from the UI that score or batch date has an effect on what “default” sorting means. Without previous knowledge of what “default” means, users whose instincts are to expect “newest first” behavior by default and who don’t see that will assume it’s random or broken.
i think you’re assuming too much about users based on your own experiences and feeds
default provides logical (enough) sort order unless you require consecutive timestamps visible in the UI
batch timestamp and current default order has been updated sometime before 2013, going by amount of complaints since then, an absolute minority of tt-rss users ever cared about any of this enough to post here 
well hopefully there’s going to be a FAQ entry soon so next time this floats up in a year or so i’ll have something to link to instead of posting about timestamps again
some UI aspects could definitely be better documented, if possible right there in the UI, because nobody would ever read the wiki or whatever. i welcome wiki contributions but it’s not like a lot of people help. well, one guy helps. that’s about it.
An impedance mismatch is entirely possible. I doubt most people use tt-rss to avoid having YouTube and Twitter accounts. I’m seeking to replicate those experiences. Instead, RSS has its roots in blog aggregation where the bar for exact sequential ordering is lower. Thanks for discussing
Another possibility is to remove the <updated/> tags from youtube or other feeds with a plugin. I think this is what I will do. The constant date changes were a bit baffling, but now I know the reason, so thank you for explanation.
Yeah, factoring out the discussion over how “default” sorting works, which is irrelevant here, it’s broken that sorting by “feed date” means sorting by published date for RSS2 feeds and sorting by updated date for atom feeds. It should mean the same thing regardless of feed format.
It’s broken that the encoding format means seeing different resolution for DVDs vs Blu-Rays. It should display the same thing regardless of disc type.
Reducing to the lowest common denominator is a sure fire way to get the worst of all worlds.
That’s a stretch and you know it. The point of blu-Ray is exactly its higher fidelity over previous formats. Nowhere is it specified that <updated> dates should be compared against <published> dates, nor is there any expectation of that behavior from users.
The inconsistency is not only between RSS2 feeds and atom feeds, but also between atom feeds that specify <updated> and ones that do not.
rss doesn’t have an updated timestamp
at least read the spec before posting your amazing insights itt
this is called having a fallback
also best part is that you’re implying that feed generators actually know how to use all those feeds correctly which is far from the truth, the whole thing is mostly just guessing anyway (which is why we have batch dates to enforce order, because feed-provided data cannot be trusted)