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
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.
I really asked myself why not use DateTime, and I hope the future video will be recommended to me.
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.
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.
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?
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
Can't express how handy this has been. Thanks for making the video.
that's a very good queestion, why you and MS team use DateTimeOffset, pls, make a video about it
I want that video about DateTime and DateTimeOffset please.
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)?
Use NodaTime!
For scenarios like this I just use NodaTime's IClock and IFakeClock
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
Can you make a vídeo explaining the difference between Datetime and DatetimeOffset?
Thanks man!
Why didn't Microsoft extract an interface for DateTime? A million people create the same boilerplate in every project.
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.
Thanks for the video! Would definitely watch a DateTimeOffset vs DateTime comparison if you decided to make one
What mocking framework are you using?
Nick, we need a video about System.Threading.Channels! Like who think the same!
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
Great video as always Nick!
Was also a pleasure meeting you at NDC (after the cruise) 🙂
I would love a video on DateTime and DateTimeOffset and all the pitfalls developers commonly run into.
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