Email Time received is different - Gmail App (Android) vs Thunderbird 102 (Windows 10)
E-mail received time in my Gmail Android app is showing the correct actual time received while the same e-mail in Thunderbird 102 Windows 10, the time received is 8-hours earlier. Please refer to the screenshots attached. Help appreciated.! Thank you.
All Replies (9)
Thunderbird takes it's date/time from the computer Timezone and time/date settings.
The info you need to post is: all the data in the headers of the email. Select email so it displays, then click on 'More' button in the header area and select 'View Source'. Post an image which shows everything in the headers - you can mask out the email address.
Please also tell us what you have as the 'Timezone' for computer.
In windows type: Date in search and select 'Date and time Settings'
what is the 'Timezone' ?
Is the 'Adjust for daylight saving time automatically' option selected or not?
Is the date and time correct on computer ?
In Thunderbird Menu > Settings > General 'Date and Time Formatting' section What is selected ?
Then select 'Calendar' in left pane What is set up as the Calendar 'Timezone'?
Pease note the date/time shown should be the date/time when email was created and set as ready to send. So if created and put into 'Send Later' then the actual time sent will be different.
If email was created and sent at 11:25 am and person lived in a different time zone then it may not be 11:25am in your timezone. If that person is in a time zone 8 hours ahead of you then it would be 3:25am for you.
Hence why we need to check all the headers and also the date/time/timezone setup on your computer and also in thunderbird.
Hello, thank you for your reply.
Both the sender and recipient of the e-mails are in the same time zone UTC+8 (Malaysia) without daylight savings. Settings requested are attached.
The e-mail was sent immediately with no delay.
Here's the view source of the e-mail:-
Delivered-To: geoklin@gmail.com Received: by 2002:a17:522:e5d7:b0:45c:44e8:a79c with SMTP id y23csp746295pvu;
Fri, 22 Jul 2022 20:25:28 -0700 (PDT)
X-Google-Smtp-Source: AGRyM1uG9HoBVg1iO7+l3x5+r4nM5Sp+D5AWmvs3sx4raF4+jJzh8dWjebBfwZTNlo9yYCrzBi+E X-Received: by 2002:a05:6a00:a29:b0:52a:c0c3:4379 with SMTP id p41-20020a056a000a2900b0052ac0c34379mr2910944pfh.15.1658546728832;
Fri, 22 Jul 2022 20:25:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1658546728; cv=none;
d=google.com; s=arc-20160816; b=YvnmmSGn7P5Qft5nuvZ511xZ1uQbL6t73CTz9JeQv/OOiw9xcPG7mI+fwIuIvyg32v bbAcjqMLyjDSvdPm1JMttcj3MGDaOl5BAhdAhXCB342ys/OAA3adel/mJ7DuQjTcJvZW A05pzBV4LrlfghEcKhEdOLDPxRftYlYsDFlPywRfU3qsIYcJxiQdXL4wUXJw9eAk/OrU rRNaNFzCLaEQ0mlrNerAuGCwdXqXzbd07z/dQ1t8n/GDlPLGhG0rSW1corYEeHHj79mz U70lgvT5Tyz+1ty4NpMpqsBgRF08ITYsSyj+/0nQDAGlPrRnPjw7MsxE53eq+7VBLUHT 35WQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=message-id:mime-version:date:subject:to:reply-to:from
:dkim-signature;
bh=wBPB5ehC+eYerfDnV51SUG+QvLCK8a800DPPWEpqLAw=;
b=rwEFGtr9X/lmdHH0jXIjQZQj3dQXFfPgz6Bhr9YU3b+T83Qk51qibJpGpuxWgE2Ycc
JxvgwCwlYkTTaGFQjbuD+1fF8+XpO+zQDRxWum/Yl1/WRIEesX0VmgHH6SSGJdAwXuD8
iylBhCo0otBs0GkUsAux+JqL3sCqe6n8NclEpB+YTNFEAUY09zazwr7ovOZZ6euGbDvq
O1HtXU6PluGeutDJm9rdK4romoNT48xwyusnsc5IKuAHMv2oTpgGpo5TwOqbhu1pnWvD
UXcYPeRO7tCXQUHFkLXPH4hRQqckCsFd2U1m86FmkAoSxfo7yiidLOL+mlUFjxNGc9Q5
VFYA==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@spamexpertfilterw.mschosting.com header.s=default header.b="oqMdd//K";
spf=neutral (google.com: 110.4.42.29 is neither permitted nor denied by best guess record for domain of apc_ups2@seonghoe.com.my) smtp.mailfrom=apc_ups2@seonghoe.com.my
Return-Path: <apc_ups2@seonghoe.com.my> Received: from spfilter-2.sew01.mschosting.com (spfilter2-out2.sew01.mschosting.com. [110.4.42.29])
by mx.google.com with ESMTPS id u14-20020a170903124e00b0015d0c53ae0esi8133777plh.491.2022.07.22.20.25.28 for <geoklin@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jul 2022 20:25:28 -0700 (PDT)
Received-SPF: neutral (google.com: 110.4.42.29 is neither permitted nor denied by best guess record for domain of apc_ups2@seonghoe.com.my) client-ip=110.4.42.29; Authentication-Results: mx.google.com;
dkim=pass header.i=@spamexpertfilterw.mschosting.com header.s=default header.b="oqMdd//K";
spf=neutral (google.com: 110.4.42.29 is neither permitted nor denied by best guess record for domain of apc_ups2@seonghoe.com.my) smtp.mailfrom=apc_ups2@seonghoe.com.my
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spamexpertfilterw.mschosting.com; s=default; h=Message-ID:Content-Type: MIME-Version:Date:Subject:To:Reply-To:From:sender:cc:bcc:in-reply-to: references:content-transfer-encoding; bh=wBPB5ehC+eYerfDnV51SUG+QvLCK8a800DPPWEpqLAw=; b=oqMdd//KaysdHOgj1tWU8KlF0e 3MTLDtJGYiku+sL9KR8kVNWuIg57I5XqlVcLQQk9CvPSvukzef3fBWrN3h4dlpNNX3YiOQndaHLSh BKVTGo+FQgSkZU3UeMTh82dg1TgwbwNG33XxHCNsvTXwwmh0P6b/NqhAsawMkZUQoLH8=; Received: from sagitaurus.mschosting.com ([110.4.46.51]) by spfilter-2.sew01.mschosting.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <apc_ups2@seonghoe.com.my>) id 1oF5lW-0008EE-WA for geoklin@gmail.com; Sat, 23 Jul 2022 11:25:27 +0800 X-SmarterMail-Authenticated-As: apc_ups2@seonghoe.com.my Received: from apc575563 (UnknownHost [175.137.127.61]) by SAGITAURUS.mschosting.com with SMTP;
Sat, 23 Jul 2022 11:25:13 +0800
From: <apc_ups2@seonghoe.com.my> Reply-To: <apc_ups2@seonghoe.com.my> To: "" <geoklin@gmail.com> Subject: NTP update successful. Date: Sat, 23 Jul 2022 03:25:11 0000 MIME-Version: 1.0 Content-Type: multipart/mixed;
boundary="951edf443c714706aebe2b66a56255e0"
Message-ID: <E1oF5lW-0008EE-WA@spfilter-2.sew01.mschosting.com> X-Originating-IP: 110.4.46.51 X-SpamExperts-Domain: spamexpertfilterw.mschosting.com X-SpamExperts-Username: sagitaurus Authentication-Results: sew01.mschosting.com; auth=pass (login) smtp.auth=sagitaurus@spamexpertfilterw.mschosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.05) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/d+0hIQ96uItQePGIgcxMfPUtbdvnXkggZ
3YnVId/Y5jcf0yeVQAvfjHznO7+bT5z9aVZ7oP/c311gbKvFErmXB37bnhC4lvX/u/c/r0vYCeW5 Rz8VBIoYqJg56LHcTLAEybI1sOftHmSKUCHCvcq0J8xIgi6BNPj7dx4YC4myx6CCaZnYVxRbZ4Ov ux9CmU9WDXUCeICOr0bziQ7HHM05K571Ms6E3wBhGy+SN+eBAOPDpjOS0zmIruTMhYvRSSUu0cgB u4XACKvBZK3NX/kVMUJTS2Jsxpkx+IHIsDarm3V1axdhVUsQxEJ2biVR7JLmRtX1Hfs7Fb9Ao09H OUrSbsR08q9tEAjFm2byf+NztGDvwHtYdYSxhouHm79/O4Vk64rk2kt6iRRBiNqTIayGJx7uL5oW qkNXwywCoo9BVP66TqBEwXEcIzLGgTpgaSjmRO2CcIQVgm9T5haIwTso17NirEYyqwqMBGrw8ELi qEARYRgJPtN81C1HvXkcYLsdyc/ke4u4k/wny7/FnZ+M/q4FRGnCQb9Qjwu36TjWnbR1IoyVcpAX xfUeXJw8PSKZyxi/aFboTUAaA09dklP/aIfVaCHpEB6cFH6WJxE4ZjdBVArvZv1zlyjFp4Ev3pUr V1oYuIV5E6Cz7x4Ai4khry/FNNZo0092wpIZOWBVyTZi0AbbDKGuhRO8U6KzLh7bofmqpBbKcS+W oQZovcAdRr2z08vJtcSwBCQjg9LFcwDl3+nIjzJyCi4y6eqWoR75WV5gKZznJurxKoEuVUxcMI8Y VskCNlbPH92V0znZIM1n8SK+/P18V3mI+V0ydTtoqabNSiXXZNjVKlnpeCtN+dWf0iD5diALYvpQ yJA+5q4wn66P7E/yWjxlWAgwA0h+pvlHhV6a5QjptwQBGybQinKWwvwTBieKnXJTVhYMtJVPkVPH kQgYp33Jw0JOCmsWM6T6hgb0dJLNfyKLko5LEBqGCQO8VXaY6h57mJayTawBEecPVOiKLiPA6YFo Yv805g8jPjKcxrullDiGL8ca3AqFXsRWVAj8unnNk9E+E2AyLzgPM5e5HMplYigO6tEWfpirH8g1 GOR1IFGt5BWm
X-Report-Abuse-To: spam@spfilter-1.sew01.mschosting.com
This is a multipart message in MIME format.
--951edf443c714706aebe2b66a56255e0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit
Name : apc_ups2 Location : BMW Melaka Contact : NG gl
https://apc575563 https://192.168.2.42
https://[FE80::2A29:86FF:FE57:5563] (Local) https://[]
Serial Number : ZA2145151845 Device Serial Number : 3S2119X13387 Date : 07/23/2022 Time : 11:25:11 Code : 0x004A
Informational - NTP update successful.
--951edf443c714706aebe2b66a56255e0--
The following is an example of how date/time can be different when you compare when sender actually composed and sent according to date time where they live, the date time as it gets received by various servers and the adjusted time for the computer where I am located.
It goes through various servers. They are in reverse order, so the top one is the last and the bottom one is the first server to get email. This is an example taken from the headers of an email I received.
Received: from previous server name by this server name for email address Thu, 21 Jul 2022 14:32:25 +0100 Received: from previous server name by this server name for email address Thu, 21 Jul 2022 09:32:24 -0400 (EDT) Received: by server name etc Thu, 21 Jul 2022 09:32:24 -0400 (EDT)
From: email address To: ME Date: Wed, 20 Jul 2022 20:45:54 -0400 This date immedaitely above is when it was written/sent by sender, but 20:45 (8:45 PM) is four hours behind me, so in my email the date/time shown is 21 Jul 2022 01:45 which is the equivalent date and time in my timezone. Note it's not just four hours ahead, it's also a different date.
In the Message List - If I enable the 'Received' column header as well as the 'Date' column header. 'Received' : shows the date/time the last server received the email: 21 Jul 2022 14:32 'Date' : shows the date/time timezone equivalent for my timezone of when email was sent by sender - 21 Jul 2022 01:45
If I choose to display the full headers and look at the Date in header then it shows date when sender created/sent email using senders date time settings. Date: Wed, 20 Jul 2022 20:45:54 -0400 You usually see the time difference (-0400) four hours displayed.
This is the kind of information I need to see for the email you are talking about, so I can explain what is going on and whether there is a problem.
As all dates and times are expressed in email as UTC with an offset and android automatically detects the timezone from the mail provider and tower. My guess is you time on the PC is correct, but your timezone is not. Windows defaults to US pacific time unless it is changed in the installation process.
The apc unity also has a timezone entry. But you are pointing to the NTP config setting the correct time/timezone as it has identified the correct time in the email.
I suggest you look in the message header (ctrl+U to see source.) and ensure that the UTC offset is actually correct in the Date header.
Thanks for the good info. I can explain aas follows:
This is the list of servers which email passed through en route to you with the last server at the top.
Received: by server name Fri, 22 Jul 2022 20:25:28 -0700 (PDT) Received: from previous server name by this server name for email address Fri, 22 Jul 2022 20:25:28 -0700 (PDT) Received: from previous server by this server for email address; Sat, 23 Jul 2022 11:25:13 +0800 Received: from previous server by this server for email address; Sat, 23 Jul 2022 11:25:13 +0800
Date: Sat, 23 Jul 2022 03:25:11 0000
So, 'Date' means created and sent by sender is 23 Jul 2022 03:25 There are four zeros meaning no time difference from UTC; you should see 03:25 am in the email 'Date'.
The very first server to receive email has this date: Sat, 23 Jul 2022 11:25:13 +0800 Server says it received email at 11:25:13 hours which is 8 hours ahead of email sent date adjusted for server timezone. The server will not get that wrong. So that server says date sent by sender is 23 Jul 2022 03:25 - then server adds 8 hours because the timzone for Malaysia is 8 hours ahead of UTC timezone.
The last server to receive the email had time date Fri, 22 Jul 2022 20:25:28 -0700 (PDT) The (PTD) means this - Pacific Daylight Time (PDT) which is 7 hours behind Coordinated Universal Time (UTC). Note: it states that server has a time difference of -0700 hours from the sender. Adjusted - 23 Jul 2022 03:25 then minus 7 hours now is in previous day 22 Jul 2022 with an evening time 20:25 Note the server will adjust to whatever the time and date of original sender date - they do not make mistakes.
Using that information: Original sender created and sent email using a device which had a time zone for UTC zone equivalent to UK - 23 Jul 2022 03:25:11 0000
Your computer says you use Kuala Lumpur, Singapore which is 8 hours ahead of UTC. So all of your settings are perfect.
You say the sender was in same timezone as the first server to receive email Kuala Lumpur, Singapore which is 8 hours ahead of UTC (Also same as you). Not sure how they sent the email eg: what program they used, but that program may not be set up to use correct date time. They are not set up for the Kuala Lumpur, Singapore timezone.
They need to check their computer or whatever device they are using to send emails. It is set up to use UTC which is Greenwich Mean Time; which is the same as used in the UK England.
There is nothing wrong with what you are seeing in Thunderbird. It can only use what the sender and server states was used. In Thunderbird - 'Date' is the date/time the email was written/sent then it uses the hour adjustment to convert to your time - but 0000 means no adjustment required.
Suggest you ask sender - Did they really create that email at 3:25AM in the early hours of the morning ?
Hello again,
Thank you again for your help and for your time!
All the examples I gave i.e. time the message was created, sent and received are at the same time. I was doing some troubleshooting with a new APS UPS set-up. In any case, I have another APC UPS with a earlier model NMC (Network Management Card) installed and do not get this type of discrepancy, that's why I suspected a problem with Thunderbird. However, I then tested the email notification (new UPS) sent to an Windows 10 Outlook Client and get the same discrepancy i.e. 8-hour time difference between event occurrence and the "time sent" stamped in the e-mail.
I have submitted a ticket to APC and hope they can help with a solution.
The attached screenshot is from the other APC UPS, you can see that the time sent 2:40pm is the same at the event time 14:40:23 hrs
Once again, thank you for your time!
This question has been locked because the original author has deleted their account. While you can no longer post new replies, the existing content remains available for reference.