Actually, I have been hoping to see TB handle the "received" column properly for quite a while now.

Sorting by "created" is NOT a workaround. The "created" date (timestamp embedded by the client of the sender prior to sending) is not the same as the "received" date on the server (timestamp embedded by your smtp server upon receival).

In TB, the "received" date is the timestamp TB has fetched the message from your pop3 server. This is ugly, counter-intuitive and simply wrong!! Reasons include:

Downloading all messages from the server. Recently I downloaded all messages from one of my servers and the received date in TB is now the same for all messages. I could use the "created" date but i am also using the "group by date feature" of the column view which is now rendered useless since that feature uses the "received" column ...

More importantly, since now all messages have the same "received" date, and knowing that the "created" date is the time the message was composed, with different time zones and clock differencies of all people who have emailed me, I no longer have any reliable time/date sorting option !!!

The same happens when you check your email after a few days (e.g. holidays reason) ...

Most other email clients properly use the "received date" column as the date the smtp server has received the message. Could the developers please either do it the same or at least add another column (e.g. locally received and received)?

If I can make TB's "received" column be the server's received date (offset to local time of course) like all other email clients i've been using then I'm sorry; please point me in the right direction.

If this is not possible then i will have to turn away from TB and all its otherwise simply lovely features!

Thank you

p.s. Other, less important problems caused by this are: a) suppose you experience problems connecting to your pop3/imap/etc server for a while and cannot retrieve your email. During this time, multiple emails still go into your mailbox and when you retrieve them they will all have the same "received" date ...; b) weird sorting if you use filters to move messages coming from different pop3/imap servers into common folders ... some of them, even if older, may end up at the top of the list because of connection problems for example; c) weird things (that may even cause problems at work, it happened to me) can happen when the connection between the sender's smtp server and your smtp server is broken for a while (you then have to look in the headers)

If you think the first two reasons I mentioned (especially the second) are bollocks then obviously I did make a mistake trying out TB. I will post this to the wishlist, maybe the devs will have a different opinion. The reason I posted here and not in the wishlist in the first place is that I thought maybe TB can do what I want but I missed the proper options/settings (which apparently I haven't).

In case you just skimmed my post then let me sumarize:

I added a pop3 account in TB. TB then downloaded all messages from the pop3 server (left by the old client). They all then had the same "received" timestamp - the date and time i hit the "send and receive" button. Within those messages are tons of messages from people from asia, europe and north america which means that the "created" date (date and time the messages were composed, local time to those users) are now pretty much irrelevant for sorting. This means there is no way of reliably sorting the messages by date/time any more. The same happens if you fetch your mail after 10 days being away. At this moment, my machine along with TB would have to be up and runnning 24/7 for the "received" date to be reliable and relevant for sorting.

If you think all that is fine then, what can I say ... fine.

You're saying that the timestamp of the message entering my pop3 server has no bearing to the moment I received it. The example above shows why the way TB does it is wrong and why the received date should be the date the delivery date to the pop3 server. That date exists in the message headers but TB simply ignores it and chooses to use the local time (my PC's time) of the moment I fetched the message, thus creating all sort of weird things and rendering sorting by date useless/irrelevant.

All other email clients work properly in this regard (e.g. outlook, thunderbird, etc). If I made the effort to post all this, it was because I like TB and would like to continue using it and bviously I would like it to improve. Your reply however, suggests (bluntly put) I should just go away and choose another email client. I have no problem with either of the two.

I don't see why TB shouldn't give the users the option of choosing between the delivery date to the pop3 server (the message headers do include this) or local delivery for the "received" date; or just add an extra field. Everyone would be happy then.

Thanks anyway. I will post in the bugtrack wish list.

Well clearly I failed to make myself understood, although already mentioning my reasons. I mentioned the behaviour here because I wasn't 100% sure I didn't miss an option somewhere that could make TB do what I wanted (I believe a user to user forum is the right place for that). I wasn't threatening with leaving since I realize it's only a user forum too - it was a freely expressed opinion.

And yes, I did everything I descrtibed .. they weren't assumptions or lies. I'm surprised you say it works fine for you. The created date of the messages I receive is always the local date of the sender which is not of interest to me (I don't really like  keeping a list of the timezone of all my senders and compute the time difference myself for each message).

You can do the follosing experiment if you like. Ask people living +N, 0 and -N hours away respectively to send you an email at the same time. Fetch your email +M hours after. The "created" date of the messages will be the date the message was composed at the client side (N hours difference between them) and the "received" date will be the date the message entered your TB inbox, the same for all messages time but M hours later than the actual time they were delivered to your smtp server (or created, almost). You have no way of telling when exactly those message were composed relative to your timezone.

I for one find it pretty weird that checking my mail after 10 days of vacation, i would get a long list of them all having the same "received" date and the "created" date being irrelevant to to actual sending time of the message relative to my timezone. Why wouldn't I want to know when the message actually was delived to my inbox relative to my timezone (which is almost the same as the time they were sent relative to my timezone)?

I so far described several experiments and situations and you say the current behavior of TB is ok and doesn't need changing. I still fail to see what would break or where is the loss in adding an option to use the received date as the date the smtp server stamped it when receiving it, or make it another field. Everything is readily available in the headers.

As I said, I would like to see TB improve on that front and that's why I took the time to write all these messages. However, I now feel I sound like a broken record so I guess TB is just not for me. I will go back to my old client which works correctly in this regard (yes, i still think this behavior of TB is wrong) - most other clients actually work correctly. I'm glad if everyone else is happy with TB. I'll check on future TB versions from time to time to see if this was implemented.

I did place an entry in the wishlist when you suggested it. Thanks.

Well then that's really weird ... in my case the created column is the local time of the sender (unconverted to my timezone) which makes it useless for sorting. That's what I was saying all along. I did numerous tests with friends at distant timezones ... it's the same: TB always puts the unconverted local time of the sender as the created date .

I'm using v3.98.1 ... did i miss anything? is there an option somewhere that affects this?