I find that I very frequently have to work with all 3 of the above objects, date strings and iso strings. Maybe that's a mistake to begin with, I'd agree with you that ideally you would keep everything in Date object, and only "format" for display/serialisation, not for anything in between. But somehow the other things always slip in, date strings come as part of API responses, json, they're also useful to do quick equality comparisons.
I find that I very frequently have to work with all 3 of the above objects, date strings and iso strings. Maybe that's a mistake to begin with, I'd agree with you that ideally you would keep everything in Date object, and only "format" for display/serialisation, not for anything in between. But somehow the other things always slip in, date strings come as part of API responses, json, they're also useful to do quick equality comparisons.
Besides some comments I feel comfortable with the name convention that you use, in fact in some cases I did the same.
I'm OK with seeing all three types being that we are talking about Javascript.
Most of the real logic should be at some other layer, where validation can be done easier, and better and with type checking.
In the UI are you at the whim of too many technologies that you can't control.
If you can control the type top to bottom, I'd urge always, always use a DateTimeOffset though.