Mails showing wrong timestamp despite a correct "Date: " value in the header
-
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.
-
There are limits to how many any non-standard inputs can be handled.
I just had a look at the source, and AFAICT the date processing done by Vivaldi's email (which is written in Javascript) appears to be done by the Javascript Date object.
In Vivaldi that is implemented by the Chromium V8 Javascript engine here
I'll note that this is code we will NEVER touch!
Essentially, if you want invalid dates parsed you will have to convince the Ecmascript/Javascript standardization group to change the definition of the Date object to allow other date formats.
-
@yngve
got it. I have sent and received more than 10 mails since last synchronization and none of them rendered a wrong timestamp.I'm not quite expecting a resolution in Vivaldi, for the reasons you mention, hence I will have to look for a workaround (e.g. separating all mails concerned in a folder, and in case needed looking for the real date in the source).
Thanks for looking into it,
-
@TCR1963 I am reasonably sure that the emails with those invalid date headers are from a limited number of senders who, as I mentioned above, are probably using "homegrown" email code, using custom date/time generator functions, in at least one case using one that is localized to the local language. They may even have fixed the issue in newer versions of their code.
Once imported those emails will gradually recede into the older emails, as newer emails arrive. Petty soon they will only be visible if you look at the emails from specific senders, recipients, or lists.
