The RIGHT way to deal with Date and Time in C#
Вставка
- Опубліковано 15 жов 2024
- Check out my courses: dometrain.com
Become a Patreon and get source code access: / 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: bit.ly/ChapsasG...
Follow me on Twitter: bit.ly/ChapsasT...
Connect on LinkedIn: bit.ly/ChapsasL...
Keep coding merch: keepcoding.shop
#csharp #dotnet
I need that video about DateTime vs DateTimeOffset.
Yeah so far not really seen DateTImeOffset used even in production code at various companies
I need it for my colleagues, I keep coming across code that's based in Datetime and its really frustrating
I'd like to see a video on DateTimeOffSet vs. DateTime as well. I get the basic definition, but don't understand why, for example, you are using it in this case instead of DateTime where only the local aspect is relevant.
Well, DateTimeOffset is your only option if time zones are important, and most often they are.
@@badwolf01 Any DateTime object that's not Kind == DateTimeKind.Utc should always be thought of simultaneously representing 38 different times, because you have no idea which time zone it's referring to, especially when you have a central database. Maybe you have a server app that's geo replicated in parts of Australia, India, Europe, US Eastern, and US Pacific time zones, with a central DB. Imagine one server updated a record with a local ModifiedDate of 2022-10-13 13:27:18.268, and another server updated a record with a local ModifiedDate of 2022-10-14 01:51:29.491. Which one happened first? You literally have no idea. Same time zone? First one happened 12.5 hours before the second one. First one happened in Central Australia and second one happened in Seattle? Then the "first" one happened 4 hours after the "second" one.
Without an offset, every time you see a local DateTime, what you have is a range of 52 different possible times it might be referring to.
Even if you aren't running in multiple time zones now, writing an application to not use offsets just means you're adding bugs that aren't affecting you *yet*.
This is exactly what I have in my projects but instead of DateTimeOffset, I'm using DateTime. Looking forward to see the comparison between them.
same here...
Unless you were 200% sure your app will never, _ever_ deal with time zones, forget about DateTime and always use DateTimeOffset. This is one of those things that cost next to nothing to implement from the get go, but are a monumental PITA to do later.
@@DanielLiuzzi even though i'm using datetime but i always send utc time to db. once it's retrieved the frontend (react) handles the local time convertion.
I would like to learn more about that too! I generally use DateTime because when working with values of this kind, it always just souded much more natural than using DateTimeOffset everywhere, since the word "offset" suggests a difference between things (like TimeSpan or so), not something you would use by default.
But note that when I am calculating time differences and such, I use DateTime.UtcNow and such. I would like to hear how DateTimeOffset gives me more certaincy of correctness with things that this.
DateTime encoded with "local" or "unspecified" time zones not reliable, since they don't actually specify the timezone, only that it was local to whoever generated the DateTime object. Always using UtcNow can mitigate this, but it requires discipline. I guess you could throw an exception any time Kind is not set to UTC, but that's silly compared to just using a DateTimeOffset in the first place.
DateTimeOffset always encodes both the time AND that time's offset from UTC (hence "Offset" in the name). When you are working with DateTimeOffsets passed around from arbitrary functions, you can be confident that you're not inadvertently interpreting the times in the wrong time zone offset.
DateTime can make sense if you don't care about time zone (e.g., a 7AM alarm should go off at 7AM local time, even if that local time zone changes).
Yes a video explaining the difference between DateTime and DateTimeOffset and Time and Timespan how Time zone is handled will be fine.
As a senior C# developer, I must say, your videos are just awsome and professional.
Yeah I love the performance ones. This one is for example more of a basic feature, but I saw too many times mids and senior fall in similar pitfalls
@@Velociapcior I can testify of that as a mid developer..
@@rubenalvarez9094 let whoever is blameless, cast the first stone
In a company I was working for a few years ago we used NodaTime and it worked just fine. It's like the implementation you showed but much more complete. It's a nuget package created by the one and only John Skeet :D
100% it’s in all of my projects by default now
For sure want a video about DateTime vs DateTimeOffset. Good video as always!
love the additional context of different teams working on .NET solving the same problem over and over. it really demonstrates how common this problem is, and how practical it is to be using the same solution in our own code.
Can't express how handy this has been. Thanks for making the video.
I would love a video on DateTime and DateTimeOffset and all the pitfalls developers commonly run into.
Nice vid, I do the same & is what Mark Seeman advocated for years ago on his old MS blog. One thing I like to do is make it an optional param and new up the default if not provided. This way I don't have to bother adding anything to DI and only pass in an non-default when testing.
Right. Ahother option would be just passing value to the function GenerateGreetText(DateTime).
Such a small change, such a gain of testability.
Great as always, thank you so much.
And yes, please, please, please, show us, why it ist DateTimeOffset instead of just DateTime.
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.
It's like you reading my mind, was having trouble with dates and time. Thanks for the video
I've for a while struggled to wrap my mind around the differences between fake, mocks and stubs and when to use which one. Do you have any videos covering this in detail with examples, or do you plan on making one in the future?
I do not but this is actually a great topic for a video. I’ll add it in the list
@@nickchapsas
Great to hear, looking forward to it then!
@nick chapsas please make the video on the difference between datetime and datetimeoffset
Nice video, It would be interesting to see an example of how DateTimeOffset should be used in a database table to track events and if that is not enough in some scenarios (future events) then how to use NodaTime.
A very good example to show the advantages of D, Dependency inversion, from the SOLID principles.
Yep we have had this discussion about the datetime va datetimeoffset in our company too we couldn’t see why in our code. So bring it on!
Thanks for your videos Nick. I would very much like to know about DateTimeOffset. Also, is there any reason for you to use NSubstitute instead of Moq? Would you recommend one over the other for any particular use case or it is a matter of taste? Best regards!
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
Thanks for the video! Would definitely watch a DateTimeOffset vs DateTime comparison if you decided to make one
I'm always interested in hearing knowledgeable people talk about dates and times in programming languages.
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
Interesting. I find it simpler ( more simple?) to create an extension method on datetime/datetimepart. It's less code, just as testable and lends itself well to domain specific language.
Hey Nick, thanks for speaking at NDC Oslo this year!
Thanks for being there! 🙏
How about passing the datetimeoffset as a parameter to the method but give it a default value of 'Now'?
Your suggestion ONLY solves that you can unit test the method. The issue is that now on the, say 10 places, in your code you put 'now' there!. Imagine that the service is something else like a connection to an api or a database or something. The callers should not be worried about putting the connection string in as an argument.
Underrated approach. You can do this with many things to turn an almost pure function (impure) into a pure function which is inherently unit testable.
Good point, my first idea was also to use method parameter with default value. Just because we can introduce millions of interfaces doesn't mean we should do that.
With parameter it takes seconds to understand what is going on inside the method.
I also pass DateTime as a parameter to the Domain layer. It's much easier to write unit tests for business logic when there are no dependencies.
I have a rule which I live by, I am incapable of writing time code. I will always get time code wrong when I eyeball it. I now make sure I TDD the time math first by writing all of my scenarios, draw up the method contract and implement the tests. Only then can I go in and write the code. It really helps to cut down on bugs that are just inevitably caused by datetimes!
We faced this problem a few months ago, where our mssql stored procedures were using Date() function directly everywhere.
Nick I would love DateTime vs DateTimeOffset video, but also I would love to see Nunit vs XUnit comparison. Personally I used both and I'm more keen towards nUnit, but I would love to see your opinion
This is less about how to use Date and Time but how to do IOC/DI for unit testing. I was really looking forward to some tricks about timezone handling. :(
I am also curious about the DateTime vs DateTimeOffset. Great video as always.
Awesome video as always! But yeah, it’ll be great to have that DateTimeOffset video as well. Cheers
As an alternative, I usually inject the IScheduler interface from Reactive. Which is actually pretty convenient, because there are lots of test helpers available for it.
Nick, shouldn't that be 'public *sealed* class GreeterService' 😉
Great vid, looking forward to the DateTimeOffset video!
It would be great a video about DateTime vs DateTimeOffset
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
that's a very good queestion, why you and MS team use DateTimeOffset, pls, make a video about it
I would love to travel back in time and redo all my projects to use this simplistic approach! Please explain DateTime vs DateTimeOffset, I would love it too
Great video as always Nick!
Was also a pleasure meeting you at NDC (after the cruise) :)
What confuses me about that Dates is timezones, especially when submitted on the browser and you handle them at the server. I don’t really know how they work or what strategy to place especially on a SaaS product that can be used in multiple timezones within the same organisation.
Nice video Nick as usual!
Quick question, you mentioned on the video you have unit and integration testing on your website. Have you also covered acceptance testing? I see you have a bundle for both but wondering if I should wait for the acceptance one so I can buy three at once
I don’t have one on acceptance testing yet but it might come late last year
@@nickchapsas did you mean, late "this" year? or "next" year perhaps?
I really asked myself why not use DateTime, and I hope the future video will be recommended to me.
Same as below! Please make a video on DateTime vs DateTimeOffset!
What are your thoughts on using NodaTime package instead? I think using Date time has more problems. As it is ambiguous what the user wants to do.
Do you have a video that deals with properly serializing & deserializing DateTime / DateTimeOffset, catering for timezones, daylight savings, etc.? This to me seems like a common issue that's not always clear too, unless you for example make use of NodaTime or similar. Would be nice to be able to just point people to a video for that.
I remember having a test that was flaky because it was testing using dates, even using a date provider kind of setup, but then it still would fail because of timezones / daylight savings, because the developer machines were not in the same timezone as the build server machines for some reason, and so some assumptions were incorrect. In the unit test, I tried to have a setup step, or make use of a using statement so within the actual execution, it would make use of a specific UI culture to use specific date formatting options.
Thanks Nick. I need the video on DateTime vs DateTimeOffset, please.
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?
Totally would like to know why DateTimeOffset and not DateTime instead. I'm also using DateTime, however, I'm only ever dealing with UTC datetimes in the backend, and they get converted at the UI layer to whatever timezone that is requested by the present user.
Did is a solid solution.
In general in most cases we need just the DateTime.[Utc]Now, so I start to just register the DateTime on the DI and injecting it in the route/service
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)?
Sure, do that
Would definitely be interested in DateTime vs DateTimeOffset. Also, where they fall down compared to NodaTime.
I would suggest to use name IClock instead of IDateTimeProvider.
I always do that, and i really feel there should be a standardized way in the framework. To overcome the fact there isn't I've made the smallest nugget package ever with only that interface ... But it's in our private nugget server...
Please make video for DateTime vs DateTimeOffset. In which usecase we must to use DateTimeOffset. I am too much confused, still I did not find any proper solution.
Used to create an interface to do this, but simpler just to pass a func which returns a DateTimeOffset in most cases, unless you really need it for dependency injection.
More people should be using DateTimeOffset, it’s even a data type in sql server. Makes life so much easier.
Atleast as long as they only work with past time (now is basically past)
For calendar like applications that won’t help much, and one would still have to grab timezone info and not just some random offset (timezones change, offsets are not bound to a specific timezone)
I really want to know about the DateTimeOffset thing. I don't think I've ever used it so I'm super curious.
Would like to see that video about DateTimeOffset as well. Especially in combination with Timespan, because I use it a lot for databinding with TimePicker controls.
So what would be the best implementation to set up a time-bind TimePicker for instance with Mudblazor TimePicker with DataTime.Kind = Local on the frontend and a DateTime.Kind = UTC => DateTimeOffset for the backend?
Can you make a vídeo explaining the difference between Datetime and DatetimeOffset?
Thanks man!
I prefer to lift the dependency to the calling code - genenerategreeting(datetime). I have used the interface strategy before but prefer a pure function until a pure function breaks down
This is what I do to where possible. DateTime is a static dependency, those can't be mocked so basically you "inject" the value through an argument.
Fancy way of saying "just pass it in".
It doesn’t matter because something will have to provide that DateTime anyway, so this example who apply for that upstream method that had to set the value as a parameter
@@nickchapsas Depends on which layer of the application you are in. I was implicitly thinking about the domain layer, where all dependencies are (should be) inverted.
If your greeter took a datetime as input it could still be tested with ease since the dependency was inverted.
The interface is a nice way of doing it, don't get me wrong, but it's also much more boilerplate than just taking DateTime(offset) as input. I know you do this as an example to get a point across, so good video non the less!
Waiting for that offset video :)
I'm always using the ISystemClock from the Microsoft.Extensions.Internal namespace. Works fine for me since this doesn't seems to be internal.
Make a video on NodaTime which makes dealing with time a lot easier across the board
What are your thoughts on NodaTime? I'm kind of leaning towards switching to NodaTime solely for testing purposes but after watching this video I'm not so sure about that anymore.
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
You can also inject IDatetimeProvider in the method if your serivice constructor is private/internal or use shims to fake the system time on test run
Yes please make a Video about DateTime and DateTimeoffset
DateTimeOffset is a very intriguing topic, please teach us :)
Yes, make the DateTime vs DateTimeOffset video please. Thanks.
Ironically, the last one you show in the video is public but it shows up in a namespace called "Microsoft.Extensions.Internal" 😂
That's the one I normally use when I couldn't be bothered creating my own interface and I've already referenced the assembly. It's pretty lightwight.
They even have documentation for it that says "Abstracts the system clock to facilitate testing."
Glad to see i am not the only one mocking time for tests 😂
Thanks for another great video Nick.
DateTimeOffset vs DateTime would be also interesting topic
Have you encountered the NodaTime package? It fixes *_all_* the issues around dealing with calendars, times and durations, as well as including a SystemClock like you do.
I’m planning to make a video on NodaTime. This video is a bit of a segway
@@nickchapsas Not sure whether this has happened yet - I can't find it if it has. Anyway, if it's still planned, I'd be happy to collaborate on it with you...
@@JonSkeet Hey Jon, it hasn't happened yet but I'd be happy to have you on a video to talk about it, especially given the new time stuff in the latest .NET versions
Yeah. Video about datetime vs datetimeoffset might be good!
I agree with others... would love to see a good explanation of why I should use DateTimeOffset instead of DateTime
And while I'm mentioning other interesting packages, have you come across PowerAssert? It takes Expressions and annotates them completely if anything fails, making it obvious where the failure is coming from.
What mocking framework are you using?
Shouldn't we keep the GenerateGreetText functions "pure" by passing in the datetime? At the moment it can give different outputs to the same input.
Huh? At the start of the example the method is indeed not pure as you have no control over the system clock dependency. However after making it depended on a IDateTimeProvider, whether or not that comes in through a constructor OR passed along as an argument on the method, does not matter. The GeerterService as a whole is pure now. There is NO way to have GenerateGreetText return different outputs anymore. Whether he calls in one time, a million times or adds a loop in the unit test that runs for 24 hours, the output will be the same.
The downside of the suggestion where methods like these will get arguments is that now you tightly coupling the usage of it. You make all the callers now pass a value. You have just created a scenario where you end up with 12 DateTimeOffset.Now sprinkled through the code base.
Imagine this would be a method that requires 4 other services it depends on. You would then put all of that 'knowledge' onto the callers. They would now have to get instances of these four dependencies, and all of the dependencies they need, etc. The whole point of dependency injection and decoupling your code .
@@paulkoopmans4620 yes, but you still need to create DateTimeProvider everywhere where you want use this code. Of course DI will for you.
I think there should be a balance between depending on DateTime as a parameter or as DateTimeProvider.
@@volodymyrliashenko1024 but that is exactly the benefit of Nick's approach. Any sort of object that would want to have a GreetMessage would only have to get DI to give a GreetService instance. DONE! Me as a caller should not be bothered by putting an argument for a provider on my constructor.
If it is something more substantial, say like a DBConnection, you would also not do that either! right? The idea is to take any impure functions/actions and abstract them away behind an interface. That way your method becomes pure. Whether or not you get it as an argument on the method or on a constructor doesn't really matter.
Why are we using DateTimeOffset and not DateTime?
I believe that was already covered in some of your's videos a bit of time ago, Nick :)
It was covered as part of a different topic. I wanted to make a stand-alone video on it in case someone missed it
What about Microsoft Fakes? Did you try to use it?
I want that video about DateTime and DateTimeOffset please.
I just realised. Good morning, Good evening and Good afternoon can be used as greetings but Good Night is a only used as a valediction (goodbye).
why do you prefer rider instead of vs ?
first thought: when the greetertext depends on a datetime, make it an parameter in the function
Ok, now unit test the thing that needs to pass down the DateTime to the function
Keep teaching to help us keep coding!)
+1 for the offsets video
I don't like this over complexed constructions 😞
I solve this with two constuctors in the 'GenerateGreetText' - one with a param DateTime and one without. And then in the constructor without parameter I get the DateTimeNow via constructor chaining to the constructor with parameter.
You will have less code, you will see directly in the class what will happens - so it is much clearer and more maintainable.
Interesting topics every time, how do you do it??
I really would like to know the real difference between datetime and datetimeoffset
Yes plz tell about Offset and datetime
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.
Need a DateTime vs. offset video
Fantastic video
Adding another vote for the DateTimeOffset video...
For scenarios like this I just use NodaTime's IClock and IFakeClock
I didn't know you could use switch return like that lol, it will be useful.
I would like the DataTimeOffset video
Need that offset video!
I would like to see DateTime vs DateTimeOffset video
Why not a function with "Date and Time" argument? :)
Because it doesn’t matter at all. Something will need to pass the date time at some point and this technique applies there :)