I'd suggest always storing it exactly as you have for eventDate - with a date object.
If you need it in any of the other ways, parse it as so when you need it.
If you need to frequently refer back to it in a particular format, use a local variable
functionfoo(eventDate){constdate=eventDate.toISOString();console.log(`The iso string for the passed in date is ${date}`);//... And whatever else you need to do with the date in that format}
To make dates less of a hassle for you, you should always only work with them in one type, wherever possible.
I can't think of many use cases where you'd need to always refer to it only as a string, or always refer to it only as an iso string, but plenty of cases where you'd want it as a proper date object.
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'd suggest always storing it exactly as you have for
eventDate
- with a date object.If you need it in any of the other ways, parse it as so when you need it.
If you need to frequently refer back to it in a particular format, use a local variable
To make dates less of a hassle for you, you should always only work with them in one type, wherever possible.
I can't think of many use cases where you'd need to always refer to it only as a string, or always refer to it only as an iso string, but plenty of cases where you'd want it as a proper date object.
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.