By adding the following OnModelCreating code to my EventContext, I was able to tell Entity Framework Core to store the Date property as a DateTime with the Kind set to DateTimeKind.Unspecified. This first problem was actually easy enough to solve using a ValueConverter. Either explicitly map this property, or ignore it using the ‘’ attribute or by using ‘EntityTypeBuilder.Ignore’ in ‘OnModelCreating’. InvalidOperationException: The property ‘Event.Date’ could not be mapped, because it is of type ‘LocalDate’ which is not a supported primitive type or a valid entity type. Attempting to run the app, I was greeted with a friendly InvalidOperationException: This is where I ran into my first problem. Public EventContext( DbContextOptions options) : base( options) This app was using Entity Framework Core and there was a DbSet for the Event class. NodaTime provides a LocalDate type that is perfect for this scenario so I declared a LocalDate property named Date on my Event class. I don’t want to deal with time at all, I’m only interested in the date the event is being held. It might be initially tempting to store the date of the event as a DateTime in UTC, but that’s not necessarily accurate unless the event happens to be held at the Royal Observatory Greenwich. In my app, I needed to model an Event that occurs on a particular date. ![]() It helps you to think about your data more clearly, and express operations on that data more precisely. Noda Time is an alternative date and time API for. That’s why the Noda Time library was created, billing itself as a better date and time API for. There is no type that represents a Date on it’s own. For example, how to I represent a date in. NET’s somewhat limited representation of date and time values through the one DateTime class. So, let's wrap the Noda's IClock interface in a static provider that is also async thread-safe :ok_hand.If you have ever dealt dates/times in an environment that crosses time zones, you know who difficult it can be to handle all scenarios properly. that NodaTime prefers the dependency injection method, which as discussed above, I think for a core cross-cutting concern you want to make the usage as easy as possible. ![]() Learn how to use NodaTime's Instant and the IClock interface which pretty much does what this is trying to do. ![]() Using NodaTimeĪ few weeks after we switched our to using NodaTime, a friend raised issue DateTimeProvider #29 that I should use Noda Time instead. After a bit of research, If you're in a similar situation, I recommend using NodaTime by Jon Skeet - it gives you the much needed confidence that you are capturing date/time correctly. In the application that I'm tech leading, we have non-functional requirements that need precise handling of date and/or time across multiple time-zones. This abstraction works well if your domain only needs DateTime and rough approximations of TimeZone, i.e. This is relatively easier to using AsyncLocal as I'll show you in a bit. ![]() One caveat of using a static implementation is that you need to async theadsafe or otherwise this will happen. I think this is a really useful feature as it allows to you to write and test time dependent code.įinally, it has a Rosyln Analyser that detects usages of DateTime.Now and in Visual Studio suggests replacing usages :lightbulb: with DateTimeProvider. It allows you to Pin DateTime so can be manipulated in a fixed scope. I prefer this approach so that you aren't forced to dependency inject an instance of IClock or IDateTimeProvider down through layers. Uses static injection that you can access DateTimeProvider.Now from anywhere in your code similar to DateTime.Now. In my (humble) opinion, DateTimeProvider has a few great features: A few years ago, I rolled up my experiences from several projects into a library DateTimeProvider. I have previously tried to solve the last point using a IClock or ITimeProvider interfaces. Allowing your code to be testable, i.e.Side Note: This is why it's important to always test in a deployed environment before handing over for testing or the Product Owner for sign-off.Forgotting that your API can be hosted in UTC, i.e.Ensuring that you can capture your domain accurately across timezones.Date and Time is one of those frustrating things in building an application that can be difficult to get right.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |