In the Date object system, before you could give a Date object the SqlDateTime, you had to instantiate it with a “New”, and if you left it off, there were consequences.
Dim ArTopRec As String = “2018-05-14 12:00:00”
Dim dChk As New Date
dChk.SQLDateTime = ArTopRec
In the new system of DateTime, do I need the “= DateTime.Now”
Var dChk As DateTime = DateTime.Now
dChk = DateTime.FromString(ArTopRec(0))
these two bits of code arent QUITE equivalent which is why you might be confused
but in the second you do not need " = DateTime.Now"
WHY you dont is a bit more involved
in the old dates you created them and could alter them by changing properties of them
so in the old code you could do
Dim dChk As New Date // create a new date (like DateTime.Now)
dChk.SQLDateTime = ArTopRec // change this date IN PLACE to a new date & time
in the new system datetimes are NOT changeable
when you get one you get it set the way it is and to get a new date time you end up needing to call a method etc that gave you a new one
Var dChk As DateTime = DateTime.Now // this will create a new DateTime and dChk will reference it
dChk = DateTime.FromString(ArTopRec(0)) // this will create a new datetime from ArTopRec(0) and
// replace the one from the previous line
so you can see that the two bits of code dont really do the same thing
In the old Dates they were “mutable” - could be changed in place without creating a new one
DateTimes are immutable - they cant be changed in place and so many manipulations actually create a new one instead
That difference accounts for much of how you have to deal with DateTime
To add years days etc to the old one you could add to TotalSeconds or any of the properties and the date would try & do the addition right - but you could get screwy results if you did things in the wrong order
Since DateTimes are NOT mutable when you add a DateInterval the code can literally take the DateTimes year month day etc, maybe in temporaries add on the date intervals year increment, month increment, etc and then create a new DateTime by using these values. And since they are all set at one time the code in the DateTime can do things in the right order and get a valid date
Immutable objects like this mean that we’re likely to be creating and destroying a lot of objects and that has some runtime implications IF you are doing such a thing a LOT
But there are upsides to it as well since its harder to have weird side effects even if two pieces of code initially used the same datetime object