With DateTime FromString, do I still have to instantiate

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

Thank you for confirming.

I like this system much better.

For clarification, “alter them by changing properties of them” , the old system is more of a “Property” based object?

I have never seen any discussion of.how languages (or whatever) are set up.

You can do

Var dChk As DateTime = DateTime.FromString(ArTopRec)

if you want.

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

Thank you. I always had problems with mutable. I get it now.