I think it is funny that you have to have Safari to watch the announcement.
It strikes me as a bit conceited. It feels like they are saying, "We are so awesome that you will go download our browser just to see our awesomeness."
When actually they just passed up an opportunity for them to get in some free advertising on me (a person who is looking to buy a new phone soon).
UPDATE: Looks like you have to have an Apple device/OS too. Lame.
I have used it in several projects. I have found that it is fantastic for getting started on a new project. But once the project gets a year or two in, it just gets in the way.
Lately we have stopped trying to use it.
The client applications does need them. But I am not allowed to expose them via OData because they are DateTime columns.
Otherwise, you can make them DateTimeOffset in .NET and map them to datetime in SQL Server. You can manage the data type mapping through the Entity Data Model designer or in code using the fluent API if you're using Code First.
As I said, the only way to do this (and preserve your naming) is to manually edit the Entity Data Model (CSDL) file.
If you're using the Entity Data Model designer having to make manual tweaks is already unavoidable if you're mapping table columns to enums.
Enums? Who said anything about enums?
At some point, just deleting all of the entities and re-adding them to reflect the changes to the database is not a viable solution to synchronizing the entity data model with your database.
Sometimes delete and re-add is the only way to fix problems with Entity Framework data models. Still, I don't delete everything and re-add. I just do this to the affected tables/entities.
Another thing you can do is to create a script that uses the API provided by the System.Data.Entity.Design namespace to automatically change the .NET type of any SQL Server datetime columns to DateTimeOffset in your EDMX file. As far as I can tell, a SQL Server datetime column implicitly converts to .NET DateTimeOffset, and a .NET DateTimeOffset implicitly converts to SQL Server datetime. So there's no need to add any special code like that in the StackOverflow page that you link.
I tried just changing the type (I hoped there was an implicit conversion too). But when I tried to run it, I got a type mismatch error.
Basically, it can't be done without a manual edit to the CSDL or changing your column/property names.
If it were just partial classes I would not complain. I have done that many times and it works great.
However, as I said before, this work around requires manual modifications to the CSDL file. That is unless you are ok with your "OrderedWhen" field being named "OrderedWhen1" or "OrderedWhenDateTime" or some such other name.
And even so, you have to change the scope of the datetime property to private (so that it does not get exposed to OData). This means that you have to remember to fix that if you ever regenerate the table (a fairly frequent practice with Entity Framework).
I suppose I could do all that. But that is just another layer of complexity in an already complex system.
When you have a lot of these columns, the time to do it adds up. But if it was one time work I could "bite the bullet" and get it done.
But this mapping requires you to edit the entity framework's CSDL. Since that CSDL gets generated code put into it, my changes can be lost when the designer updates the file or another developer drops and re-adds a table.
Yes it is a solution, but a dirty one that should not be needed.
Why is it useless? There is only one scenario where you wouldn't use DateTimeOffset: You are writing an application that will never do anything across time zones.
Before you answer, consider the fact that due to the daylight savings transition, your app will cross time zone boundaries at least twice a year.
I agree with this if you have the luxury of blue sky development (meaning you get to start from scratch).
But if you have hundreds of DateTime columns in your system, and a way to deal with the timezone problem already in place, then DateTimeOffset is a lot of work to just get you back to where you already are.
Which is why I am frustrated that OData decided to drop DateTime.
So as the owner of a breaking change that is security related in ASP.NET they're not easy to justify. The next version of ASP.NET will turn off the ability to disable viewstate mac. It will break people. I'm not sorry about it. We started talking about it 9 months ago, and issued preview patches. If your app breaks frankly it's for your own good :D
I don't think that dropping a data type and fixing a security hole can be considered the same kind of breaking change.
Especially when the OData team could be backwards compatible with DateTime and while offering the new DateTimeOffset at the same time.