ko.toJSON and timezones

[jre...@me.com]

When you call ko.toJSON on a model with a Date property, in the resulting JSON it automatically converts the timezone to UTC.

So for example if the date on the client is 2013-06-26 10:00:00 AM GMT-5, after running ko.toJSON the resulting json will output: 2013-06-26 05:00:00 GMT-0.

When this gets posted to the server, from the server side code there is no easy way to know what the client's time zone is, and due to DST complications it could be a mess to find out exactly the textual representation of the date/time the user entered.

Is there a way to disable ko.toJSON switching the timezone to UTC? Or maybe a feature that could be implemented to allow this option? For now we're just passing the dates as strings but I know it's not the optimal solution.

Thanks

[peter...@ultimatesoftware.com]

I haven't dealt with this directly, so I'm not sure if there's a better solution, but would it be possible to have another variable to keep track of the user's time zone on client-side, and then pass that along?

[Ryan Rahlf]

Dates can certainly be a pain to work with, but it's important to understand a bit about what's going on behind the scenes.

The primary thing to understand is that a certain time is a certain time, regardless of what time zone you're in.  If an asteroid strikes earth, it hits at a specific moment in time.  It's the exact same moment in time for everyone, everywhere...the only difference is what their clocks say.  This is easy to visualize with this cool tool : http://everytimezone.com/ ; when you "switch" time zones, it's not the time that changes, it's the clocks.

That's the underlying principle behind dates and times in every operating system and language that I know about.

So, the two times you mentioned in your post are the same moment in time, only with the clock shifted.  You can safely store that time on the server in UTC.  When you display the time for the client, you take the UTC time and "shift the clock" (adjust the time zone) on the client to match the local clock on their computer.  This allows your app to service users in any time zone.  

The most common reason that your times would be incorrect is when the user's computer clock is wrong.  That's another nice feature of this truth about times...as soon as they fix their clock, the times display correctly again.

One thing I'll add here is that your server and your database may not be agreeing about the time zone either.  I've run into issues with MS SQL server and ASP.NET not agreeing when saving and loading times.  If anyone else runs into that error, take a look at .NET's DateTime.SpecifyKind() after loading your UTC time from the database: you may have to set the kind to UTC for things to start working correctly.  Usually the "kind" of dates loaded from SQL will be "Unspecified".

I hope this helps!

Ryan Rahlf

__________________

http://RyanRahlf.com

@Ryanthem

[jre...@me.com]

I think that may be what I do. Would use getTimeZoneOffset and pass that through as an extra variable and then reconstruct the date object in the C# side.

[jre...@me.com]

Thanks for the background info. I get the feature of saving time in UTC and auto-adjusting it depending on the client, although depending on the use-case it may not always be what you want. The particular project I'm working on, dealing with flight times, requires input and output dates to always be fixed.

[Ryan Rahlf]

Well, "use caution" is my best advice.  Of course I don't know you're use case, but the idea of a "fixed time" is problematic.  Moments in time are always fixed.  Only how the time is displayed changes.  If a flight leaves at 5:00 PM Eastern, it also leaves at 4:00 PM Central and 3:00 PM Mountain.  The flight only leaves once, at a fixed point in time.  If you want the app to display the correct time for the user (so they don't miss their flight, I assume), you'll need to take the local time zone into account at some point.  

As an example, most smart phones will automatically update the clock display to the local time when traveling.  Say I booked my flight in the Central time zone and am looking up a connecting flight on my phone while waiting at the airport in a Eastern time zone.  If the display of the flight data doesn't reference the local clock on my phone, I'm going to be an hour late for that flight.

Another piece of this puzzle is the way that dates are standardized for representation in JSON; they're not.  I believe that the eventual standardization will be ISO 8601 and there's a good post on that here : http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx with some extra info here : http://stackoverflow.com/questions/10286204/the-right-json-date-format

Dates can be a mess, but it's a beautiful thing when your code starts to handle them across boarders with no issues.  I hope some of this background will be helpful to you. Best of luck!

-Ryan

--
You received this message because you are subscribed to the Google Groups "KnockoutJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to knockoutjs+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jre...@me.com]

Just had another related issue: handling Date of Birth.

DOB is an absolute date, ie. when representing it to the client it should always be the same and there should be no TZ concept. I'm guessing using strings is the only way of doing it instead of a Date object.