Mails showing wrong timestamp despite a correct "Date: " value in the header
-
I have synchronised my IMAP Account with Vivaldi Mail, however, all items contained in the sent folder are shown with the timestamp of the first synchronization, noat when they have been sent originally. This renders the mail client useless to me ... and I wonder why is this since in Ist das Problem bekannt? Ich möchte hier gefragt haben bevor ich eine bug report aufmache.TB it works out without any problem, hence I consider the items are ok at the IMAP server.
I just discovered that the problem also applies for some mails in the Inbox, and the values of the "Date: " variable in the headers are like:Date: Mon, 31 Mar 2014 21:50:56 CEST
Date: Sun, 12 Jun 2016 12:07:26 CEST
Date: Thu, 06 Oct 11 08:00:52 MEST
Date: SA 04, MXR 2006 19:59:12
Date: DI 05, DEZ 2006 04:55:23
Date: Mon, 31 Mar 2014 21:57:11 CEST
Date: Mon, 31 Mar 2014 21:57:11 CESThowever they are shown like:
Is this a known problem? I wanted to ask before opening a bug report, did the same in the german-speaking forum.
Many thanks, -
@TCR1963
Hi, you use the Vivaldi mail client with a vivaldi.net mail account, or is is a different provider? -
no, it is with a different email provider, STRATO.
I'm using Thunderbird on Linux today, and the iOS mail client on the iphone. None of them have such problem. -
@TCR1963
OK, we need a user with a STRATO account, my providers doesn't show this issue.
Freenet, Yahoo, Gmail, Outlook and Vivaldi. -
@mib2berlin
happy to support with samples of how these headers do look like. It is quite strange that they are not shown correctly in Vivaldi.
For the mails concerning sitting in the inbox, only a few, I have copied the header data into my original mail, as per the advise in the German speaking forum.
Regarding the sent folder, 20x more items imacted, but definitely not all of them.
Hence I consider it a problem with certain formats provided by the "Date: " variable in the header (?) -
@TCR1963
You can report it to the bug tracker and add some headers to the report. The Vivaldi team have a lot off test accounts, it maybe better instead of wait for a user here.For information on how to report a bug, see this URL: https://vvld.in/how-to-report-bugs
Once that is done, please share the bug number (beginning with VB-).
Add your vivaldi.net username, please.
On the form, you can add your email address. Once submitted, you'll get a confirmation. You can reply to this with any logs or further info.Cheers, mib
-
@TCR1963 said in Mails showing wrong timestamp despite a correct "Date: " value in the header:
Date: SA 04, MXR 2006 19:59:12
Date: DI 05, DEZ 2006 04:55:23These are not standard-compliant date strings
The others may not be compliant with the standards either, given the time zone designators; they should be e.g. "+0100" or "UTC".
If the client cannot decode the date field, it will fall back to something else, which I believe is currently the date/time of receiving the email.
IIRC back in the Opera email client we only recognized 3 date formats, and two of them because they were used historically.
Example of a valid date field:
Date: Thu, 10 Apr 2025 07:01:58 -0700 (PDT)Which translates to April 10, 16:01:58 CET (daylight saving time)
Developer and Security Expert at Vivaldi.
-
Thanks yngve,
must be kind of that, but I have mail with headers formating "Date: " likeDate: Wed, 7 Aug 2024 12:23:40 +0200 (CEST)
where the timestamp is displayed correct.
Question remains why Thunderbird is able to handle and Vivaldi not?
-
@TCR1963 It depends on how much effort those developers spent (or wasted) trying to accommodate sending agents that do not comply with the standard(s) for email messages (and if they don't comply with the format of the date header, it might be that they do not comply with other, more important parts of the format, as well)
I would not be surprised if the other client only accommodates specific alternative formats for specific named sending agents, and does not accept the same format from other agents. (IOW, I suspect they are using email agent sniffing; it takes a lot of research to discover all the ways things can "wrong").
-
yngve,
I understand the concern, however, the combination of STRATO as service provider and Thunderbird as email client should be seen as a reference. Both are major players in the ecosystem.
The interesting thing is: All new mails that I send after the first synchronisation are showing the correct timestamp, and they have the correct format for the date in the header. All of them have been send by TB.I have opened a bug report, let`s see what the development team thinks about it. I'm offering to collect data, if no other user with a STRATO account is available.
Many thanks, -
@TCR1963 The primary reason for being careful about working around standard compliance bugs is that it convinces other software developers that what they are doing is "correct", and in some cases (probably not dates) such workaround can introduce security (or privacy) vulnerabilities.
I'll also note that two of your examples involved country specific day and month names. Then the question becomes which of the 200+ countries and more languages do we support such dates. Just Europe, or Asia, other continents and regions?
IMO this is something we should NOT try to work around.
Re the other client, if you were using it at the time those emails were sent, it may have actually create a timestamp close enough that you might not notice that it too used the time of receipt (or it might have used the timestamps from the intermediate servers forwarding the email).
In any case, your report is missing (at least) information about which sender agents were involved (or what other identification can be obtained). My guess is that they are "homegrown" corporate mail list servers, that whoever developed the software did not read the relevant IETF RFC standards, and not any of the generally available email clients or list servers
My suggestion is that you should look at the email headers and determine who sent them, using which software, and if they are still sending bad dates, you should report the bug to them.
-
BTW, I had a look at the Thunderbird android repo, and AFAICT they are handling invalid dates just like Vivaldi (date invalid -> use received date).
The report is from 2016, and is still not resolved, and AFAICT there have been no patches (pull requests) referencing the report, and the last comment was in 2022
https://github.com/thunderbird/thunderbird-android/issues/1356
-
So Thunderbird was showing the almost correct date because the internal received date was just after the email was sent, whereas Vivaldi's received date is when Vivaldi imported the message.
-
The Bat! from Ritlabs parse invalid dates better.
I do not know what other clients do with invalid Date headers. -
@DoctorG said in Mails showing wrong timestamp despite a correct "Date: " value in the header:
The Bat! from Ritlabs parse invalid dates better.
I do not know what other clients do with invalid Date headers.That long-lived clients (like The Bat!, Thunderbird, …) handle non-standard and obsolete time zones better is unsurprising given their development has evolved with the RFC standard for Internet Message Format
-
@yngve said in Mails showing wrong timestamp despite a correct "Date: " value in the header:
@TCR1963 said in Mails showing wrong timestamp despite a correct "Date: " value in the header:
Date: SA 04, MXR 2006 19:59:12
Date: DI 05, DEZ 2006 04:55:23These are not standard-compliant date strings
The others may not be compliant with the standards either, given the time zone designators; they should be e.g. "+0100" or "UTC".
If the client cannot decode the date field, it will fall back to something else, which I believe is currently the date/time of receiving the email.
IIRC back in the Opera email client we only recognized 3 date formats, and two of them because they were used historically.
Example of a valid date field:
Date: Thu, 10 Apr 2025 07:01:58 -0700 (PDT)Which translates to April 10, 16:01:58 CET (daylight saving time)
Where:
-
Time Zone meaning is unclear it should be treated as -0000 and not result in rejection of remaining Date header value
-
Date: header is invalid or absent then the client has no option but to use the current date and time of receiving
-
-
I have no clue why Vivaldi Mail's Date parser will not be made more resilient against weird date format strings.
Would give it more acceptance as a mail client. -
The interesting thig is that all new mails that I send, and all that I receive, are shown correctly regarding timestamp. Which may lead to the conclusion that the problem only occurs at first synchronisation. And this is irrational, as the headers are not changing. Need to provoke getting a mail from a sender that earlier has sent a mail with non standard header, this would be interesting to know.
-
@TCR1963 the incorrect timestamp seems plausible if you have imported the emails from Thunderbird or if you have set up the account later. Thunderbird probably received the emails shortly after they were sent, so the timestamp there looks ok because it's just slightly off, even if Thunderbird uses the received date rather than the sent date.
-
Hmm, this makes sense, then it would be just by coincidence that the timestamps for those mails are, kind of, correct.
But then the same would happen if I would import the mails from the same IMAP Account to a TB client on another machine... ...and I did that a couple of times in past without observing such behavior.
Anyway, in case I'm the only one with the problem then I will have to live with it, I'm afraid. In that event, however, I will stay with my TB client, in peace.
