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.
Related
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?
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'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.
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.