This project is read-only.


Query: Better support for DateTime operators


It would be great if linq to entites could parse more common DateTime properties and methods such as the Date property and AddDays() within a linq to entities query. For instance currently if you wish to ignore the time portion of a DateTime member in a linq to entities query then you have to use EntityFunctions.TruncateTime(object.DateTimeProperty) instead of object.DateTimeProperty.Date. This solution currently doesn't work with Sql Server CE 4.0. That is one issue but I think a far bigger one is that a bigger api disconnect is introduced between linq to objects and linq to sql etc One of the beautiful things about linq is (for the most part) a query that runs against linq to sql has a very good chance of running against linq to objects. This is fantastic for such things as the specification pattern. I understand that different providers will not necessarily be able to parse every expression tree that can be handled by other providers. However using EntityFunctions or SqlFunctions guarantees that it won't, as it is now tightly coupled to linq to entities. I would like to see more effort in making properties such as DateTime.Date and methods such as DateTime.AddDays() work in a more homogeneous way when compared to the other providers. Hope this is taken as constructive feedback.

This item was migrated from the DevDiv work item tracking system [ID=147251].

This work item originated from A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Closed Dec 12, 2016 at 10:22 PM by RoMiller
EF Team Triage: We are transitioning this project to GitHub ( As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base ( Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include:
  • It was a bug report that does not contain sufficient information for us to be able to reproduce it
  • It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it
  • It is a feature request that we are realistically not going to implement on the EF6.x code base
    Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider ( We will no longer be monitoring this issue tracker for comments, so please do not reply here.


RoMiller wrote Jan 24, 2013 at 11:41 PM

EF Team Triage: We agree that this would be a good scenario to enable. Taking into account where we are in the EF6 release along with the size and the impact of this feature our team is not planning to implement it in EF6. Therefore, we are moving it to the Future release to reconsider in the next release.