![]() Not only if they are across different time zones, but also if you need to things like time travel and display data at a certain time of the day. NodaTime is a great library to use if you are building applications where you are handling a lot of date and times. Depending how far along you are with your project. Then create your migrations, update the database and also you might have to update the queries. Options.UseSqlServer("your DB Connection", Īfter the NuGet Package has been restored all you need to do is update your SQL Server configuration as follows: using .Extensions ![]() Fortunately there is an open source package that can be used for this.Īdd the following packed to your project: For example LocalDate should be a date type in the database. If you are using SQL Server and EF Core to store your data you need a way to convert the NodaTime types into SQL Server types. Public static string ToShortDateString(this LocalDate local) Public static string ToShortDateString(this LocalDate? local) On the other hand user generated values should be represented as one of the following:Īn example what changed in our source code Before public class Event System generated values should be represented as Instant values. To summarize it in a few words, there are two sources of date and time data: system clocks, and the user. If you are wondering which type to use for which kind of property, this docs page has all the relevant information. The NodaTime documentation is very thorough and detailed and should be your main guidance. This is a big difference to the C# DateTime construct. NodaTime has different types to represent different types of dates and times. But why reinvent the wheel if there is a great solution out there. The first thing every engineer will do is try and create an abstraction for the C# DateTime and most likely succeed sooner or later. The other issue that I faced in this project that some used the extension methods ToUniversalTime or ToLocalTime, which can have effects that if not properly handled will break your application. Of course you can configure this, but how many times have you forgotten that? You will lose any information in the database of the type of DateTime, so when you get an object from EF Core the DateTime kind might not be specified as UTC, even though you might have stored it this way. Another issue is that if you are using DateTime and EF Core, by default it always creates a datetime2 column type even though sometimes you only need the date or time part. Most developers knew that dates should be stored in UTC not everyone was doing it this way and also as Jon Skeet wrote: "Storing UTC is not a silver bullet". If you have read the blog post from Jon Skeet, this can lead to the biggest issues. I was working on a project that had many date and time properties all over the place, especially also dates and times in the future. Why should we consider switching to NodaTime? So basically the main problem is not the construct itself but how developers are using it and that it is not powerful and meaningful enough. ![]() which in turn makes it hard to treat the data consistently. Both platforms provide far too few types to represent date and time values in a way which encourages the developer to really consider what kind of data they're dealing with. NET for the same reason that Joda Time exists for Java: the built-in libraries for handling dates and times are inadequate. If you are interested in more details, you should read the following blog post by Jon Skeet ( ). ![]() If you want to show the correct timestamp to the user according to his time zone setting, the C# DateTime construct would be enough for most of the scenarios, but it does not supply you with a nice and understandable interface. Also you might not know from where the client will access your application and you want to present the date and time in his local time zone. In my opinion it is one of the hardest tasks to get right, also due to the cloud, you do not know where your servers will be hosted and their local time settings. In this blog post I wanted to share some insights of how to make sure you get your time zones right in a globally distributed system. As a developer you have probably had many discussions in your teams all around date and times.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |