I've got a Rails JSON API that gets called by my client app, ie:
[GET] /posts?time=today
Previously I was getting today's date by calling Date.today, but this causes bugs because it uses the server's timezone and not the user's timezone.
I know it's a long shot, but is there a way to fix this without having to update the client to pass in the current timezone? I could do an IP lookup, but it seems too heavyweight. Is the timezone information passed in anywhere in the request?
Related
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.
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.
I have an ASP.NET MVC3 Restful web service that uses the Microsoft JSON serializer. This service returns data that contains a .NET DateTime value.
The web service is accessed by a Silverlight client that uses the Newtonsoft JSON library to deserialize the returned data.
The date value that I get in the client are five hours ahead of the value that are sent from the service. Since I am in the Eastern Time Zone (US), this appears to be localtime being sent from the service getting interpreted as GMT by the client.
My question is this: What is a good way to handle this discrepancy? Is there something in either the Microsoft or the Newtonsoft library that I can set to deal with this. Something a little more elegant than subtracting 5 hours from the time received by the client.
Thanks
First have a look at this question (it is about Backbone.js, but applies to your problem as well): How to handle dates in Backbone?
Some libraries (like Jackson) serialize dates to UNIX time by default. How is the date/time represented in the data sent from the server? If it is not a simple integer, it should be represented using ISO 8601 which always explicitly defines timezone (or Z for UTC time).
If the time is sent in textual form from the server, but without time zone, the server marshals it incorrectly. If the time has correct time zone but the client discards it - it is the client fault.
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.