Question: Naming date variables

How do you name local date variables for date strings vs Date instances? Been doing it inconsistently, and not sure how to tackle yet, but considering enforcing the following:

const eventDate = new Date("2020-11-06")
const eventDateStr = "2020-11-06"
const eventDateISOStr = new Date("2020-11-06").toISOString()

Otherwise, things get confusing, dates are hard as is, naming them inconsistently makes things worse. Normally I'm not a fan of putting types into the variable names, but not sure there's a better way here (not interested in types in this case.. the naming is important for code readability and writability).

Comments

[Benjamin James]

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

function foo(eventDate){
    const date = 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.

[Karolis Narkevicius]

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.

[Austin French]

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.

[Juan Carlos Choque Quispe]

Besides some comments I feel comfortable with the name convention that you use, in fact in some cases I did the same.

[webbureaucrat]

The naming convention here is pretty good. I agree types in names isn't ideal, but I think you've got a good reason.

However, if you want more descriptive names than type names, consider naming them by where the values are coming from or where they are going. Presumably there's a reason why you're representing dates as strings / ISO8601s, so is this an eventDateForDisplay? Is it an eventDateFromJson?

[Austin French]

I'd argue this is the correct way to use Hungarian notation. Especially in JavaScript.

with the caveat that actual usage matters. If this was meant to be a private class for example, I'd prefer to see something like:

   getCalendarevent(id) {
   let selectedEvent =  events[id];

   showEventViewer({
   title: selectedEvent.name,
   dateString: selectedEvent.getDateString(),
   location: selectedEvent.location
  });
}

where the "Event" object looks more like:

  Event = {
  title;
  date;
  location;

  getDateString = function(){
   return this.date.toString();
  }  

}

[Karolis Narkevicius]

Didn't like that. Will try a bit of a different convention:

const eventDateObj = new Date("2020-11-06")
const eventDate = "2020-11-06"
const eventDateISO = new Date("2020-11-06").toISOString()