The RIGHT way to deal with Date and Time in C#

Software — 11/10/2022 · 23 Comments



Check out my courses: https://nickchapsas.com
Become a Patreon and get source code access: https://www.patreon.com/nickchapsas

Hello everybody I’m Nick and in this video I will show you how you can use DateTime and DateTimeOffset correctly in your code, to make sure that it is testable. This is a technique that even Microsoft themselves are using and it is considered a best practice when dealing with time and date sensitive code.

Don’t forget to comment, like and subscribe 🙂

Social Media:
Follow me on GitHub: http://bit.ly/ChapsasGitHub
Follow me on Twitter: http://bit.ly/ChapsasTwitter
Connect on LinkedIn: http://bit.ly/ChapsasLinkedIn

Keep coding merch: https://keepcoding.shop

#csharp #dotnet

23 Comments

  1. Yes, more videos on DateTime, offset and Noda. DateTime is one of the things, besides decimal and thousand separators and encoding/none latin chars, that "none US"-developers are spending too much time fixing in bad code.

  3. Nothing to do with testability. This techniques has been used for centuries in financial software that creates reports with historical dates. As a rule always layer the current date time. It is good practice to layer all environment variables.

  4. I’m using this for years, although recently I started using the implementation with methods instead of properties—IMHO, it makes more sense, as it shows that we get (meaning calculate) this value each time instead of just reading the property. The property suggest that each time the returned value should be the same, unless the state of the object has changed.

  5. I kind of understand why everyone uses DateTimeOffset, but I'm interested in how well it works with EF Core. I know SQL Server added a new DateTimeOffset type, but what about other databases?

  6. I always struggled with built-in types as you have to be constantly councious if you work with local time or UTC etc.. All the issues were solved once I switched to NodaTime package, which has much more precise types + it's clock should be always injected from DI

  10. You provided a full DateTimeOffset instance knowing very well that your SUT only needs the hour component.
    To me, that makes it look as if the whole instance is needed, as if the year 2022 that you set is actually relevant for the test, when it is not.
    What are your thoughts on only mocking the specific part you need, something along the lines of '_dateTimeProvider.Now.Hour.Returns(18)' (or something similar)?

  13. I've been doing this for a few years now. Ultimately I decouple dependency to most things that are concrete so that I can make all my code testable. Didn't realised internally .NET had so many implementations of the same thing though. I'm all for standardising it, but then it's such a simple interface I think leaving it to people to do their own specific way isn't so bad.
    I'd love to see your take on DateTimeOffset vs DateTime

  15. Why didn't Microsoft extract an interface for DateTime? A million people create the same boilerplate in every project.

  16. So basically this is just another reminder to apply the concepts of dependency injection for datetimes the same way as for many other things, so that you can unit test easier, thanks to the obtained effect of decoupling of such dependencies.

  20. Thanks for your videos, watching you program reminds me of how joyous and orderly programming can be. I'd like a video on why use datetimeoffset vs Datetime

  23. I prefer a optional parameter using nullable datetimeoffset. If null, I default to system time. If used within the class, and scope of use is ok with a captured time at instanciation, then I can see this pattern as well

Leave a Reply

© 2023 53GB