Off earth you have a launch criterion and accumulated subjective seconds. That's your onboard time.

There are no days, weeks, months, years. Just count the seconds and make sure everyone knows the epoch you started at.

Now, let's suppose you have a permanent settled outpost on Luna. You still use accumulated seconds as your time basis, but for casual conversation, you can talk about any Earth time marking that makes sense to you -- next Tuesday, or March 20th, or "in three months". You might occasionally care about whether it's bright or dark outside, but the tidal lock means that local weeks and months really aren't useful.

The hard thing is when you actually care about both the time on Earth and the local time/date/season of a planet you are interacting with naturally. Let's hypothesize a terraformed Venus, and while we're at it, let's change the axial tilt from 2.mumble degrees to 24 degrees. That gives us a 224ish terrestrial day V-year, a 1.92 V-day V-year, and approximately eight seasons per V-year, each being 56 days long.

On that planet, you get to go outside and enjoy the fresh air, but you want to know what season it is more than you want to know what month it is:

dark-winter, dark-fall, dark-summer, dark-spring

bright-winter, bright-fall, hell, bright-spring

(Venus rotates backwards, that's why the seasons are all funny.)

But when you want to know when the next shipment of Earth whisky is coming, you ask a computer.

Mission elapsed time just complicates things. Now that we have enough memory that we don't need to worry so much about overflow, we just use the Unix epoch even onboard spacecraft.

Unix time is not really great for any scientific purpose; it defines each day to have exactly 86400 seconds. (So, eventually you have problems with leap seconds.)

UTC is better, because at least it is aware of leap seconds, but performing any calculation spanning a year's end involves consulting a database of leap seconds. Notably these aren't determined much in advance, so such calculations involving future dates will also involve leap-second errors.

TAI is best (for non-relativistic non-sidereal purposes), as it is not adjusted to account for leap seconds. You can calculate with it without trouble.

(All three of the above are based on the atomic SI second, so despite their differences, their seconds tick synchronously.)

In astronomical contexts there are good alternatives to the epoch (like TDB, mentioned in another comment). I interpreted the top-level question as relating to day-to-day measurements and representations of time, presumably for use by extraterrestrial humans, since the commenter asked in the context of handling time zones and units like weeks and months which are irrelevant in a scientific context.

UTC is not a great choice for a universal interplanetary time system, as it's designed to work on just one planet, for just one calendar system. It'll work fine while we're asking humans on Earth to oversee robots on the Mars, but will fall down pretty quickly once humans take permanent residence on celestial bodies that don't have Earth's rhythms.

Well, the general idea seems usable enough; X time units from a specific reference point. Conversion is then done to whatever local time-keeping system you might have.

Leap seconds are based on conditions here on Earth and wouldn't really be needed on Mars or Venus. They might have different peculiarities though, and they wouldn't be usable on Earth. In that situation, a single point of reference would be useful for conversions.

Right; "X time units from a specific reference point" is what TAI is. Taking Unix time and removing the notion of leap seconds is effectively a circumlocution for exactly that standard :)