In C# 10, we now have the DateOnly and TimeOnly types instead of just DateTime. See how to use them in this 10-Minute Training video. Full Courses: iamtimcorey.com Source Code: leadmagnets.ap... Mailing List: signup.iamtimc...
Lovely explanation. Currently enrolled for C# Foundation series. Keep them coming Tim. Also appreciate the 10 minute format videos like others have said.
These seem like a long awaited addition, not something I may use too often myself, but I could see this becoming far nicer for code-to-database scenarios utilizing down the line
Yep. That’s the best recording time for me right now. I’m building a recording studio so that I can record during the day. I’m hoping to have that up and running next month.
@@IAmTimCorey that is amazing news, I hope you continue to grow and share your knowledge with us. Congrats on the studio, we hope to get you back to day hours soon 😎
So used to having to write TheDate = DateTime.Now.ToString("dd.MM.yyyy") and TheTime = DateTime.Now.ToString("HH:mm:ss"). Glad things have improved over the years.
it take 21 years for Microsoft to come to this solution which was very simple from the beginning itself. Even here there was no need for only in those data types. Date is just date no need to tell DateOnly when the other alternative is already DateTime.
The problem is that we always see others' problems as easy and our own as difficult. In this case, if they left off the only, they would have caused problems for literally hundreds of thousands of people. It isn't a "simple" problem. It was a complex situation brought on by a desire not to make breaking changes. They made a hard decision with few good options.
Hey Tim. Thanks for the video and I liked the new option for date. But question is how does it work if we use this in EF Core Entity model with Code First approach. Thanks in advance
Great video, new Time raises with C#10 I guess. How this compares with DateTimeOffset where you also not getting rollovers due to date offset stored? Is this not solving the issue already, or is there a missconceotion on my side?
I also like the 10 minute format as many others here have commented. Would also have liked to see the DateTimeOffset also mentioned quicly too (as it also appeared in the intelisense at one point - especially when you also mentioned the timezone handling stuff - that the DateTimeOffset handles far better than just DateTime. Once again, a great little snippit.
Awesome, this was a long time coming! Finally we won't need to write unnecessary code and use up resources because we just wanted the "dateOnly" or "timeOnly" in our code. I don't know about the rest of the community, but we sure use dates a lot in our software, so this is going to help a lot. I also love the format of the 10 minute video, but I do feel that the longer, more in depth discussions, are still needed for those topics that you would not be able to explain in 10 minutes or less.
Wouldn't be better if the DateOnly property of a model could be translated to sql by the fluent api?! Nice 10min format!! Congratulations Tim and thanks a million for helping us
That's more of a full Monday video format rather than a 10-minute video format. I will be covering DateTime (and these new ones) in a future Monday video.
Awesome feature, there are lots of instances for me where I only want the time or the date. Thanks for putting this into the 10 minute format. Perfect amount of explanation.
A great short video on little topics or changes to keep people up to date. It seems like they could have just broken up more methods to the DateTime object to show dates or times, but it gives other options.
Dealing with date and time is a pain in most languages.. so this is always welcome! Not the same thing but C# has had other date'ish objects like TimeSpan.
Nope. Those properties still give you a DateTime but with the "irrelevant" part at the default (so 10/21/2021 12:00:00 for the date). These new objects are just the date or just the time. Yes, it is more efficient.
Useful but need to be careful as it cannot be converted to UTC to compare with other DateOnly and TimeOnly objects. Example: you said the TimeOnly can be used to show the open and close times of a store. What if someone from a different time zone wanted to know if your store was open right now so they could call to place an order. The website might be misleading showing it was open when it was closed and vice versa. In some ways this feels like a throwback to the way things were done in older languages.
Think of this more like the writing on the door for the hours rather than the times on Google. But even the times on Google take into account the time zone of the location. You don't need the time zone on each time if you know what time zone the store is physically located in.
I'd like se how to work with timezones in Blazor: displaying the date in the timezone of the client, editing the date and sending the date back to the server. With normal dates, but also with DateOnly and TimeOnly.
The main question is that how does this look like 'under the facade'? Do DateOnly and TimeOnly have their separate implementation that is not depending on DateTime class? Because if not than it's just some heavy syntax sugar thing going on there=))
But seriously what good are these types without out-of-the-box JSON and EF SQL Server support? Looks like we have to wait until Dot Net Core 7 for this.
Can I use this new types to map an entity propperty to database field use EntityFramewokr ? Wondering how will entity framework handle these types against a database.
Thanks for the video. Leave it to the .Net team to add unnecessary words to an object name. I thought maybe there's Date and Time aliases or something, but nope.
I covered that in the video - there is a Date alias in VB that would have caused a conflict. There is also the property off of DateTime called Date that returns a DateTime at midnight that would have been confusing.
I think this is probably only useful for weird edge cases, if at all. All the benefits for string conversions can also be gained from just learning the relevant formatting symbols. The “weird rollovers” are important because they are telling you something true about that moment in time. To pretend time zones simply don’t exist will lead to more user confusion.
I don't think it is that limited. Think store hours. When you post store hours in the window, you don't include time zones. It is a physical location, so the time will be in that location's time zone. The same is true for birthdays. I don't specify a time for my birthday, just a date. I don't specify which time zone that birthday is in either. Christmas is on December 25th. There are a lot of dates and times that do not relate to a specific time and date in a specific location. They aren't the majority, but there are a lot of them and so far, we have been working around them by specifying date or time parts that are ignored.
@@IAmTimCorey Fair, but those examples are typically just for the purposes of display, no? The moment you try to do any work (math) with them is where you can run into trouble. In my day job role, I set the standards for the developers, and I build a time tracking app that is used by geographically distributed teams on the side. Because I've seen far more than my fair share of temporal arithmetic problems and I spend a lot of time trying to cordon off pitfalls for others, I may be overreacting here. I have been annoyed multiple times by having to deal with DateTime & TimeSpan when it comes to things like binding to UI controls, etc., so I can see why this kind of thing is exciting. I'm just concerned that some folks might see this as an upgrade that resolves the weird things they sometimes see because of timezones, leaps, etc. and not know they're really just sweeping them under the rug.
I don't but that sounds like a good video suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
The DateTime object doesn’t contain time zone information either (as you could believe from the video). DateTimeOffset is the object of choice to store the time zone along with the DateTime as DateTime is limited to specifying whether is is considered local (the computer’s time zone), UTC or unknown.
The DateOnly is so good that I decided to redo my custom blazor calendar control to use dateonly instead of datetime since using a calendar is intended to choose date but not time.
Lol this videos comes out while i'm working on a project that uses a javascript calendar in Blazor, so I need to pass dates between js and .net. Dates are so fun, even more parsing them back and forth lol i need help
@@IAmTimCorey Yes C#10 only works with .Net 6, but how can this be a new "language feature"? There is nothing new in the language for that, its just new datatypes added in .net 6. There is no new keyword or language feature to learn for using this. I'd say its just a .net 6 feature - and yes you will have to use C# 10 for this, but its not a language feature.
I've always just used NodaTime because the built in DateTime classes make no sense except in the most trivial of cases. Microsoft should just deprecate those classes and start again from scratch in my opinion. Conflicts between object names should have been handled with namespaces.
Deprecating doesn’t mean the names go away and removing the names would break TONS of applications. A namespace “fix” would be tricky because we would have to change the default namespaces to exclude the old ones.
@@IAmTimCorey I fully understand what deprecating means, and that's exactly what I meant. You have to keep them around but marking them as [Obsolete] sends a strong message. Now create a new namespace and make a sensible date-time library that actually works well and doesn't have some funky semantics.
It isn't that simple. If you put them in a different namespace, you would have to reference them manually (so it would be NewDate.Date and NewDate.Time or whatever namespace you called them). Otherwise, they would conflict with the existing names in System.
I covered that in the video, I believe. VB already had a Date type. They couldn't override that type because it would cause a difference in behavior, which would break backward compatibility.
could you transform a DateOnly + TimeOnly in a Datetime?, i say because theres sometimes for example when you have a picker for dates and other for hours, you save them in this DateOnly and TimeOnly but you need the DateTime for googlecalendar or any other calendar. Or maybe you want to do some operations with the hours or date and after that get the new datetime.
Will this mean that EntityFramework will now parse SQL DATE and TIME into these rather than a getting confused when a DateTime object translates back into a SQL DATE?
This is great, not something need all the time but I definitely have use cases when I only need the date or the time only. Will EF Core support the mapping to a date/time column?
oh, man.. I'm really gonna need the source code for this one.. not like that async await stuff, that's so obvious it's self evident.. but this. man.. I just don't know.. even with source code, will any of us understand? lol. :) Seriously though, thanks again for a great explanation, Tim!
I work with a lot of databases that have separate date and time columns. Will be nice to have more specific datatypes to use on the CLR side of things.
This looks great, really curious how it integrates with SQL/SQLClient, many times when needing to deal with dates/dateTimes we will find out in certain use cases there will be issues. You look at what MS provides and think great this should be really nice, only to find out later what seems logical for how things should work then won't in some edge cases. I'm certain we will see some issues around edges cases when interacting with the different SQL's DateTime column types, code i've had before would have issues depending on the underlying DateTime for the column definition itself, but more the interaction between Sql, ADO.Net and Entity Framework. Would suggest make you test this good...
Finally! It only took like 20 years for Microsoft to do it! Almost no time at all! 😂. Buy seriously, I have been wanting this since the first day I started programming!!!!!!!
Thank you very much for the content and this new-to-me shorter video style. As a paid RU-vid Member, I really appreciate not having “paid promotions” in your videos to include an overview of your channel. If you could at least embed a “skip intro” to quickly get past the channel overview I would like it.
I think where this is gonna really be useful is when we're presenting or displaying what dates and times are. I think from a calculation standpoint I would probably keep using DateTime. Thanks for showing this!
What is wrong with using: string fullDate = DateTime.Now.ToString() or whatever suitable string method string dateOnly = fullDate.Split( new char { ' ' }, StringSplitOptions.None )[0]; string timeOnly = fullDate.Split( new char { ' ' }, StringSplitOptions.None )[1]; in this way you have timeZones accounted for and how about wrapping all this into a string Extension accessible from fullDate (just to keep date and time linked to same value of DateTime.Now) - and add 2 functions called GetDateOnly() and GetTimeOnly() or whatever meaningful names.
I'll use it quite a bit. The times I used timestamps is in the database - I put a timestamp in to mark when the the record was added or updated... outside of that date is usually sufficient.
1. Thank you for a 10 minute video. you have alot of good information, but sometimes as you said, you just want the basics to get up and running. 2. Many times i just wanted the date only or the time only. this will help a lot.
