The DateTimeOffset CLR type is a struct, mainly composed by a DateTime struct and a TimeSpan struct (the latter expressing time zone offset).
In SQL Server 2008 and above, there is also a corresponding "datetimeoffset" native SQL server type that maps nicely with EF.

The idea of this data type is to be able to represent a date/time, but also a specific time zone.

Note! The DateTime type is sufficient to calculate exact universal times (by always practicing dates stored as UTC etc.), but it has no information about the time zone e.g. of the user that modified some object.

In the JavaScript Date type, there is no way of expressig different time zones, but the JavaScript date type is aware of the user's current time zone.

In the current SPA project I am working on, I wanted to always use the DateTimeOffset property in all my POCO entities to e.g. store information about the time zone of the user that creates or modifies an object.

To accomplish this I use the ISO 8601 string representation (with milliseconds and exact time zone) when serializing dates to JSON, both on the server and on the client.

When the client script serializes a JS Date to JSON, it always expresses the current time zone on the client in the ISO string. When the client deserializes the ISO date string, it always adjusts the date to the client's current time zone.

When the server deserializes the ISO date string, it always deserializes to a DateTimeOffset, keeping the time zone info specified by the client. When DateTimeOffsets on the server serializes themselves to JSON, the ISO string will express the time zone offset of the DateTimeOffset.Offset. (This works out of the Box with Json.NET)

I found this to be a very well-functioning practice in a globally distributed solution.

I wanted to explore Breeze to help me with the communication with my Web APIs, but my testing was put on hold when I found that DateTimeOffset types are unknown on the client.

It would be really nice if you could implement support for the DateTimeOffset data type, since it is provides a consistent way of dealing with dilemmas of time and location in globally distributed applications.

Breeze seems fantastic, but I don't want to compromise the other good practices implemented in this project just to make Breeze work.

I hope that this case will be considered important, looking forward to a solution!

I'm curious as to what you guys are cooking up for Angular...It seems like it could in theory be pretty easy as angular binds to plain objects, but I'm sure there are plenty of wrinkles. Glad we have brilliant minds such as yourselves to figure this stuff out!
Just off the top of my head I'm thinking in the query promise callback you could set the array to what forEach is observing via an angular.apply() call, since we're outside of angular. Or better yet somehow integrate the promise with forEach since this is what angular uses if I remember correctly. For saving changes, I'm not sure if breeze just iterates the model or needs notifications, if its the former than that would be easier I guess. Anyway keep up the great work!