I have a different view on the importance of time to a starship operator.
I believe it is EVERYTHING, at least in terms of defining a jump, astrogation in general, and defining a detection, position and course.
In terms of a jump, consider that every stellar system is in motion.
Our own solar system is travelling at 828,000 kph. A jump plotted just a year ago would put the ship a LONG way off from the 100D limit because the entire system moved away from that position at considerable speed.
The jump Generate program has to deal with system movement, orbital movement of the body you are trying to get as close to, and if you are using a random time assumption that is not entirely known, enough of a margin at the extremes to not be too close to the planet on emergence (effectively having to allow for a very large safe zone).
You need to know the PRECISE time in order to make use of any mapped hazard database. An asteroid that will cause a collision right this minute is likely not a hazard just 5 minutes ago or 5 minutes later.
Don't tell your navigator you cannot give him/her/unspecified alien gender the time cause it's not important, there will likely be a scene, quite possibly a sulking, and maybe constant ship log entries protesting unsafe conditions which will be used by your insurance company in the suit regarding refusing damage payment for the comet you collided with.
Finally, if you are reporting a detection or even an enemy position, it is vital to have some sort of timestamp or you will lead friendly forces astray.
A pirate location sent to the local SDB patrol that is 20 minutes old and they don't know it means that pirate ship could be going a lot faster when they receive and plot an intercept. The zone of possible pirate movement they are working from will be wrong and they will have greater chances to miss an intercept if they are not in direct detection range.
Similar problems obtain with naval battle contact reports that do not have a proper timestamp.
So IMTU this and the 'ship time does not match external reference time' issue is resolved by proper formatting of location and event logging.
A detection result (ship, navigation hazard, destination, etc.) is formatted with TIME FIRST, so that accurate decisions and logging can occur.
Example of typical report-
Contact 15120-00032, designated Threat 2 on our plot, Time 15120-23:07:00 HACK, contact position MARSREF bearing 270 by 136, 11.2 million kms, contact course SOLARTRUEREF heading 190 by 200, 200,000 meters per second.
Normally one wouldn't want to use shifting references, probably a hurried report to get across relative position quickly in battle.
Note that without an accurate time, even a reference to a well known astrogation feature to report the plot by would be inaccurate, have to know the time to get any relative position right, even if you are using something like Galactic True.
Although any self-respecting TL30 Jump-128,000 capable craft would be using the Big Bang as the reference AND time point, please we aren't LOCAL IGNORANT SAVAGES.
Re: logging different ship time, IMTU since time passes LONGER on the ship then in the 'real world', I have the convention YYYY-MM-DD HH:MM:SS@DD:HH:MM:SS, with the time after the @ being the time that has elapsed on ship.
So 2215-06-21 10:15:23@00:00:00:00 is the time the ship went into jump, 2215-06-21 10:15:23@02:18:09:42 is when the surprise birthday party the steward put on for one the passengers occurred.