Our experiments have shown that GMail does not use UTC for the internal dates in its mailstore. Anyone know what offset it uses? We've narrowed it to between 3 and 7 hours behind UTC (exclusive), and we could figure it out with further experimentation, but maybe someone knows off-hand. UID SEARCH and the like aren't very accurate if you are assuming UTC and it's not the case. :-)
Further, we're wondering if it's consistent regardless of where you're connecting to gmail in the world.
Update: the first test showed UTC-4 or UTC-5, and a second test I did (sending hourly emails) revealed my account to be UTC-7. We're wondering if it's set when you register depending on your source IP (I also registered an account with a UTC-10 timezone and the internal store was still UTC-7. And changing your account timezone later doesn't change the internal store date an IMAP client sees, wisely, I would think).
I had written a python IMAP lib client and confirmed that the Gmail timezone is UTC-07:00 and I have confirmed it over and over again. So, any search results that you obtain (more precisely the after: startDate and before: endDate query) are shifted by that much amount according to your local timezone. This is because the mailstore uses the local time according to the sender SMTP server, which in case of gmail happens to be at UTC-07:00.
Related
We're using ejabberd as our xmpp server and iphone xmppframework for client side.
The problem is when we get the offline messages the timestap that is written in the message is in actual date/time format but the timezone of the server is different than the clients time zones so at this point the things are getting messy.
We're using a same approach while querying Last Activity of a user(XEP-0012) , but in last activity xep the server returns the information as "how many seconds ago the user last logged in to server" so in this way we can apply seconds difference to our clients time and found the message delivery date/time so there is no problem in Last Activity query.
But in delayed delivery , ejabberd sends an exact date and time value and clients confuses about the conversion(Date and time of each client may be very different from each others)
Does anyone know how can we fix that problem? Is there any way to configure ejabberd to return "seconds passed information" until offline message send ?
By the way we're using latest ejabberd version.
Thanks
XEP-0091 (Legacy Delayed Delivery) says:
The timezone is be understood as UTC.
So you need to convert the time from UTC to the local time of the client in order to get the correct result.
The newer specification, XEP-0203 (Delayed Delivery) also says:
[...] MUST be expressed in UTC
I have an application that automates email communications between my companies service desk and customers.
When the application needs to reply to an existing email, i use FindItems to get the email and then i load the properties i need, then i use (CreateReply) to get the response email i need to send.
The strange behavior is as follows:
The email i need to reply to has a correct SentDateTime and timezone (+4 GMT) but when i create a reply from it the sent date of the "replied to email" becomes UTC which makes no sense!
I am specifying the timezone when i am connecting to exchange correctly and i cant seem to find a way to specify the timezone of the created reply message.
I really hope someone knows anything about this.
Just to point out, when i use outlook to manually reply to emails, the replied to email sent date time is correct. The problem only happens when i use exchange web services.
Regards
Yazeed
This problem happens because the EWS Managed API omits sending the TimeZone headers in most requests. For the reply, forwards you do need send the timezone headers else it will set the header information to UTC. One workaround is to use the events to add the timezone header back in see http://blogs.msdn.com/b/emeamsgdev/archive/2014/04/23/ews-missing-soap-headers-when-using-the-ews-managed-api.aspx . The source for the EWS Managed API is also available now so you could also patch the GetTimeZoneRequired method and recompile the library https://github.com/OfficeDev/ews-managed-api/blob/31951f456519786e41232fa9ff6a3ab20b56cac3/Core/ServiceObjects/Items/Item.cs .
Cheers
Glen
I've an API which uses oAuth for authentication.
Everything has been working smoothly for months until last week, when I started noticing oAuth was throwing 400 errors due to a Expired timestamp, yours X, ours Y.
I'm guessing that some changes on server (it's a shared hosting machine) reset or messed something with the local time.
I can't figure out any other reason, but I'd like to know if there's any other debuggin' technique that may help me.
PS: Using PHP 5.2 and the oAuth 1.0a php implementation
The OAuth server should always use UTC time as the basis for checking timestamps. Assuming that you send the correct timestamp based on UTC, check the 'ours' timestamp has the correct time in UTC. If not then its most likely there is a problem with the server time or the OAuth timestamp calculation on the server.
Pl help me. I'm saving the date in UTC format. while displaying it, i'm converting it to local time. but it is displaying server time. How can i display the date by identifying the client timezone?
I would venture a guess here that you are doing the conversion in C# code as part of an ASP.NET website.
Converting to local time converts to the local time of the machine where the code is actually executing. Thus, when you convert to local time, you are converting to the local timezone of your server machine, not the client machine.
To convert to the client local time, you need to know the local timezone of the client machine. Unfortunately, the standard ASP.NET HttpRequest does not include that information (mostly because the HTTP protocol does not specify a standard way for the client HTTP agent to pass its local timezone to the HTTP server). Multiple people have come with various solutions about this problem; here's one recent blog post about Handling TimeZone Information In ASP.NET that can help you.
I know this one is the weirdest of all weird questions I have asked till date. But I have a reason.
The problem is that I have a no of websites hosted in diff servers (I dont own these servers) and every website has some pages where I have to enter some execution date and time. The date/time I enter should be of the timezone in which my website's host server is running.
Just want to know if there is any good utility/website which can tell me the timezone/location of my web host if I provide the web site address.
You can put on each of those servers your own "system" page that will display the current time.
<%= DateTime.Now.ToString() %>
And you will access it like: http://site-no-x.com/timecheck
Something like this. Simple and effective.
ADDED: Keep in mind also that web servers and database servers can also have different time settings. If a hosting company (theoretically) keeps the web server farm on East coast and has the database servers on West coast, you will see different dates returned by .NET's DateTime.Now and SQL's GETDATE().
This isn't likely to be possible, as timezones are set at the OS level. (i.e.: You'd need to check programatically on each server itself using your language of choice.)
As such, it might be easier in the long to fix the scripts.
So you can't modify the code to have the thing use UTC?