Summary

For a DateTime property configured with HasDateTimeKind(DateTimeKind.Local), anything the server computes from the stored value (date parts, date arithmetic, truncation) is evaluated in UTC, because the value is stored as a UTC BSON date and the date operators are rendered without a timezone. The result differs from what C# (and EF materialization of the same property, which reads it back as Local) would give. This affects both the driver-LINQ path (the released default) and the native translator.

This is separate from the read-back fix done on the EF-322 native branch (commit 28613f67 and follow-up): that fix makes native read back Local-kind values correctly (GroupBy keys, $min/$max, terminal Min/Max, join leaves). It does not change what the server computes.

Affected shapes (measured on EF10, host time zone Europe/London)

• Date parts in projections and filters, e.g. .Hour, .Day, .Date over a Local-kind property: computed from the UTC instant, so off by the zone offset.
• Computed dates over a Local-kind property in projections, e.g. AddDays(1), .Date: returned with the wrong kind and/or wrong ticks.
• Set operations or conditionals mixing a Local-kind and an Unspecified/Utc-kind date in the same result member.

Example shapes:

db.Orders.Select(o => o.LocalDate.Hour)
db.Orders.Where(o => o.LocalDate.Hour == 11)
db.Orders.Select(o => o.LocalDate.AddDays(1))
db.Orders.Select(o => o.LocalDate.Date)
db.Orders.Select(o => new { D = o.PlainDate }).Concat(db.Orders.Select(o => new { D = o.LocalDate }))

On the native branch, the computed-date and mixed-kind set-op shapes now decline, so in the default Native mode they fall back to driver-LINQ, which returns the same wrong answer the released package gives today. Date parts are wrong on both paths. HasDateTimeKind(Utc) and unconfigured (Unspecified) properties are not affected.

Decision needed

1. Render date operators ($hour, $dateTrunc, $dateAdd, ...) with the host's local timezone for Local-kind properties, so server-side results match C#. The host zone is a client-side notion and can differ from the zone the data was written in, so this needs thought.
2. Or decline these shapes on both paths (clean translation failure), since no server-side rendering reproduces C# semantics exactly.

Either way, add differential tests asserting Kind and ticks against entity materialization, with zone-independent values.

References

• Found during EF-322 native GroupBy work; see the DateTimeKind read-back plan docs/superpowers/plans/2026-09-29-native-datetimekind-readback.md on branch EF-322-Native-LINQ-rebased.
• BsonSerializerFactory.GetDateTimeSerializer is what honours GetDateTimeKind() on read-back.