Skip to content
This repository has been archived by the owner on Dec 14, 2017. It is now read-only.

DateTime Kind not set properly upon account retrieval from EF repository #620

Open
SteelsenS opened this issue Feb 24, 2016 · 2 comments
Open
Labels

Comments

@SteelsenS
Copy link

Migrated from IdentityServer/IdentityServer3.MembershipReboot#37

A sample demonstrating the issue is available here

When a user account is retrieved from an EF based repository the "Kind" property of the account is not set (Kind = "Unspecified") which can lead to unexpected behavior downstream - an offset may be applied to a time already in UTC. "Kind" is set properly as soon as the record is saved or modified.

The root cause is that EF doesn't allow you to specify a default Kind for DateTime. This has been discussed multiple times on SO, e.g., here, here, here.

Copying from the previous issue report:

Options to remedy are essentially:

  1. Switch to DateTimeOffset from DateTime (this is being discussed separately here Using DateTimeOffset instead of DateTime (Neo4j store) #388)
  2. Modify the accessor of DateTime properties to set the Kind property
  3. Modify the dbContext to respect a new attribute for datetime kind on account properties
  4. Modify the dbContext to enforce a UTC datetime kind on all datetime values retrieved from the DB

All of these could have side effects depending on how people are using DateTime values. (1) is a breaking change, (2) and (3) could affect people overriding the base Created/Updated/etc. properties, (4) could cause unexpected behavior for people who have extended RelationalUserAccount with custom DateTime properties that are for some reason not persisted in UTC.

Ideal resolution will probably be either (3) or (4) depending on feedback here.

@brockallen brockallen added the bug label Mar 16, 2016
@SteelsenS
Copy link
Author

This fell off my radar but I noticed it in my queue. @brockallen - any preference on which path to take? I'm happy to submit a PR but since there are side effects to every option would like your feedback first.

@brockallen
Copy link
Owner

I think I prefer (4).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants