If nothing else is using this, I would keep this internal to this file.

We have functions that already do this in our preferred formats that are also international friendly.

export function formatDate(timestamp) {
  const rawDate = timestamp ? new Date(timestamp) : new Date();
  const date = rawDate.toLocaleDateString([], { year: 'numeric', month: 'short', day: 'numeric' });
  const time = rawDate.toLocaleTimeString([], { hour: 'numeric', minute: '2-digit' });
  return { date, time };
}

EDIT: I just realized you may be doing this to get into a format you need for datatime-local input. For some reason all the string concating rubs me the wrong way, but it's not a hill I would die on.

I would probably return null.

Loosely:

1. If DA / NX gives you null we purposefully did this based on input supplied.
2. If DA / NX gives you undefined "something" in the machine is truly undefined.
3. If DA / NX gives you an empty string... it's fairly rare and likely only because we need to concat a string.

Same addition as above... if the input cannot take a null, it's a totally valid and good usecase to have it be an empty string.

_isScheduled is fine. No need for the type, either. If these micro frontends become so big we cannot figure out that this is a boolean, we can pivot.

I'd avoid doing setters unless absolutely necessary. Especially for booleans where lazy falsey checks (!this._isRegisteredForSnapshotScheduler) will result in the same outcome.

If you're not waiting on DOM to render, you can do this in connectedCallback which should only run once.

firstUpdated is for use cases where you need to know the DOM inside the web component.

https://lit.dev/docs/components/lifecycle/#firstupdated (this whole page on lifecycle is great, btw)

I try to leave these lifecycle events as trim as possible and kick out to other functions.

This way, as a fellow developer, I do not have to digest all of your code below when simply trying to see what's being fired off when this lifecycle function loads.

We like early returns.