wrong date sort
Hello, Please tell me, according to this code, on which date should the email be sorted for received in the Date column: August 6th or June 8th? The email was sent on August 6th, but TB sorted it into the Date column on June 8th? Why? Where is the problem?
X-Real-To: [email protected] Return-Path: <[email protected]> Received: from smtp-00-g00.cmailpro.net ([0.0.218.89] verified)
by 00.cmailpro.net (CommuniGate Pro SMTP 6.2.15) with ESMTPS id 147527890 for [email protected]; Tue, 06 Aug 2024 12:32:17 +0300
Received: from 00.nra.bg ([0.0.164.234]) by 00.cmailpro.net with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <[email protected]>) id 1sbGY0-003ybw-S0 for [email protected]; Tue, 06 Aug 2024 05:32:07 -0400 Received: from localhost (localhost [127.0.0.1]) by 00.nra.bg (Postfix) with ESMTP id 001CE1AE8076 for <[email protected]>; Tue, 6 Aug 2024 12:32:04 +0300 (EEST) X-Virus-Scanned: amavisd-new at nra.bg X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue Received: from 00.nra.bg ([127.0.0.1]) by localhost (00.nra.bg [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxbm9TzTgVsA for <[email protected]>; Tue, 6 Aug 2024 12:32:03 +0300 (EEST) MIME-version: 1.0 Content-Type: multipart/mixed;charset= windows-1251; boundary="----=*#abc1234321cba#*=" Content-Transfer-Encoding: QUOTED-PRINTABLE From: <[email protected]> To: [email protected] Date: 06-08-2024 12:32:03 Subject: =?WINDOWS-1251?Q?=D1=FA=EE=E1=F9=E5=ED=E8=E5=20=EE=F2=20=EE=F0=E3=E0=ED?==?WINDOWS-1251?Q?=20=ED=E0=20=CD=C0=CF=20=E7=E0=20=EF=F0=E5=E4=EE=F1=F2=E0?==?WINDOWS-1251?Q?=E2=FF=ED=E5=20=ED=E0=20=E4=EE=EA=F3=EC=E5=ED=F2=E8=20=EF?==?WINDOWS-1251?Q?=EE=20=E5=EB=E5=EA=F2=F0=EE=ED=E5=ED=20=EF=FA=F2=20=E4=EE?==?WINDOWS-1251?Q?=20=20=ED=E0=20=CF=F0=E8=E7=EC=EE=F1=20=C5=CE=CE=C4=20=F1?==?WINDOWS-1251?Q?=20=C5=C8=CA=20202432360?= Message-Id: <[email protected]> Received-SPF: pass (00.cmailpro.net: domain of 00.nra.bg designates 0.0.164.234 as permitted sender) client-ip=0.0.164.234; [email protected]; helo=00.nra.bg; X-SPF-Result: 00.cmailpro.net: domain of 00.nra.bg designates 0.0.164.234 as permitted sender Authentication-Results: 00.cmailpro.net; iprev=pass (00.nra.bg) smtp.remote-ip=0.0.164.234; spf=pass smtp.mailfrom=00.nra.bg; dmarc=pass header.from=00.nra.bg Authentication-Results: cmailpro.net; spf=pass [email protected] X-cMailPro-Class: ham X-cMailPro-Evidence: dnswl/se-reputation (trusted ham) X-Recommended-Action: accept X-Filter-ID: K9WxaI5ZGhh8Ak/JwIjqX37XzRs1GEYk6SAtIkozCW98mBrJY5hMhwwSJ9O+DYtSjj/4RTK0qtH0
x30jZGzXZkAgbt5PmrF5kJEOcTY3YWAyaHBs68x9hT+ZyTNKzXjKPGFvO7YGatqzr+ah4Hu2ctgz cDoFd+96Xw4QUNtTnXQtFAc5X+O83ozS6UBxIG7pQP5fOQxS+0vImCSvDvsWZx9r P8nzZFNTsK3MFKxhBA0BSjcooU0BtzK4QHYeseo+3c/j9uly1Zg1NSDJHcrwPY4ocfm Wv3Fe9Idq+A=
X-Report-Abuse-To: [email protected]
由office818于
所有回复 (7)
re :The email was sent on August 6th, but TB sorted it into the Date column on June 8th? Why? Where is the problem?
Example: In the UK, the date : 6 Aug 2024 is written 6/8/2024 In the US, the date: 6 Aug 2024 is written 8/6/2024
But in 8/6/2024 in the UK is seen as 8th of June. This may explain why you have a date in August being displayed as a date in June.
The EEST = Eastern European Summer Time
I'm trying to understand where you are located, what your computer is using in timezone and what regional settings you are using because Thunderbird uses your computer settings when it comes to the date.
Please check: the time zone on your computer and the regional settings. Is your computer set up to use a UK style or a US style of date formating ?
In Windows: In search type: Date select 'Date & Time' option Is the 'Timezone' correct for your location ? What Timezone was set? Did you need to alter it ?
Scroll to bottom and select 'Date, Time & Regional formatting' What is set in 'Country or Region' ?
'Regional format' what is this set as ?
Then under 'Related settings' select 'Additional date, time & regional settings' This opens Control Panel where you select 'Change date, time or number formats' The formats tab allows to choose how the date is displayed. Post an image showing what you can see for the date and time formats.
I apologize for not specifying these details. I use TB from Bulgaria, which is part of the EU. Here the format is dd.MM.yyyy I am attaching photos.
Those settings are correct.
Do you see the date display error in all emails or just that particular email ?
Can you post an image showing: Settings > Calendar
I'm looking for just the top most section where it mentions Date text format, Timezone, Day and Week Views.
In this email and in those that nra.bg sends me. If you notice for separator in the date they used "-". Do you think this meets the standards?
I was trying to rule out an issue with any settings on computer and in Thunderbird. Just check...In Thunderbird Settings > General scroll down to 'Date and Formatting' section Have you selected 'Regional settings locale:' and it's set to Bulgarian Bulgaria
Date – timestamp of when an email client sent an email, standard follows the format of day, dd month yyyy hh:mm:ss. For example, Date: Wed, 16 Dec 2020 16:57:23.
however, the example you posted is non-standard eg: Date: 06-08-2024 12:32:03
Info on compliance standard: https://datatracker.ietf.org/doc/html/rfc822#section-5 https://datatracker.ietf.org/doc/html/rfc2822#section-3.3
Having said that, I deliberately altered a received email header to use same non standard date and it did not effect the display in the Date column header - but it does fail to display in the Message Header area. I'm trying to recreate the same issue - misreading month as day and day as month - and failing at this point.
I created email to send via a google server to another server. Prior to sending I altered the Date to use the non standard format and also not todays date although the time was correct for me.
- Date: 06-08-2024 14:20:31
The receved email source view showed this:
- Date: Wed, 14 Aug 2024 06:22:29 -0700 (PDT)
- X-Google-Original-Date: 06-08-2024 14:20:31
So the gmail server altered the non-standard date I had entered when sent via gmail.
Created and sent another email with non standard date from account A to a gmail account. Gmail did not alter anything being received. Date is ok in Date column but not displayed in the Message Header area - unless I select to display all headers.
However, in your email I also notice there are other detected issues: X-Amavis-Alert: BAD HEADER SECTION,..... which may effect things.
For the bad email - in View Source - At the very top - do you see the first line saying something like this: From - Tue, 6 Aug 2024 12:32:04
What is at the very top ?
First I want to thank you for your time!
When I use my phone which has iOS and has their email client built in, this email is displayed and sorted correctly. If I view it through the web platform (pronto.cmailpro.net) it also sorts correctly. The problem is only with TB. The TB setup and the first row - I am sending pictures. About this error "X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue": I don't know what it means.
I've been trying to find something which is using an American setting because they use the date setting where month is prior to date.
I notice the second image says : The Application locale is English (United States) Even though it's not selected I'm wondering whether something is effecting your display when you get emails that are not following the universal standard.
Language: English (US) This is a setting that would auto use the American style of formatting.
See if you can select 'Language - English (GB)'
Just changing the Language may not be enough. Alternative is to remove anything to do with the US. Uninstall the Thunderbird English (United States) program, then download and install Thunderbird for English (British). You can still select the REgional Setting locale for Bulgaria, but this time you should be able to select Language English (GB). So not much would change in that respect.