I have discovered a bug, I think.  I went through the bug posts for 2.51 and couldn't find anything like it, but who knows?

To start I am using a fresh install of 2.51.  No mods or anything unusual. 

I started a single-player race campaign with limited starting tech featuring a humanity that had been conquered and oppressed by aliens for quite a while, before they mysteriously left just as the human resistance was close to defeating their human proxy troops. The humans get their act together and begin exploring the solar system, looking for the aliens, and expanding and building a fleet in case they find them.  I pushed this campaign about twelve years down the road, from 2400 to 2412, before stopping because I was considering starting a different campaign with multiple player races. 

I created the second game in the same database and played around with it for a bit, but never got much beyond the start phase, mostly due to a crippling Fallout 4 addiction, as my son helped me mod the base game and add a lot of new content. 

Either before I created the second campaign or just after I noticed Steve's campaign that comes with the database and I deleted it. 

After the Fallout 4 addition abated a bit I felt the need to get back to Aurora, so I opened up the game and decided to go back to my single-race game, as it was farther along and better developed.  However, the dates are now screwed up.  As noted above, the campaign started at 2400, and went out to March of 2412 before I quit.  My log document verifies this.  When I opened up the campaign, the dates in the Events window are in August 2068.  I checked the image I had made of the starting conditions and that verifies that the campaign started on the year 2400 as well. 

I don't know where this date came from.  The other campaign I created, with multiple player races, started in the year 1, so it doesn't seem to be cross contamination from that. 

I don't know how this happened, and the campaign is essentially unusable because the dates don't match my log document (potential campaign write-up). 

Kurt   

...I noticed that this situations are most common in non Real System starts or if you mess around local systems connections.

The settings for this game were 75% local, 30 spread, which is now my standard game setup.
It gives plenty of interesting loops, and relatively few short/boring loops.

In terms of mapping, unless you extremely unlucky, you can use the matryoshka approach.

Basically, long connections run around and inside you have the rest of the systems, if you use a squared map system.

If you use a spiral approach, you should then be able to keep the same approach by dragging the connections on the out arms and spiral inwards.

Skoormit, out of curiosity can you send your DB? I would like to have some fun with your map. I am asking because I never really encountered a really messy run in terms of inter system connections. I guess I have been lucky (or unlucky, depending on point of view) so far. It is true I only play with Real Stars map, and I noticed that this situations are most common in non Real System starts or if you mess around local systems connections.

Steve, in your case you only need to switch the position of Tannauser gate on North West side and move Kodiak up of Andromeda.
Once you done that, you should be able to quickly figure out the best position for Barbarossa and Dark Heaven to pass on the west side of Sol while keeping Paragon and Argonar in the right place, as they don't need to intersect. Proxima connection can be placed anywhere free and out of the way at this point.
I'll admit that Regulus will require some creativity. To be fair, create space for that part of the galaxy should be doable until a new connection turns the table. I think you'll have to skew the whole map to the south west side until you can squeeze the last intersection through Lethe, considering Alpha Centauri should be already in an ideal position due to the previous Barbarossa move.

If I may, this presents the perfect opportunity for me to brainstorm on a couple of ideas. If you ever played Avorion (please don't or Aurora will get put aside for too long ) I like the warp concept there, so basically the map does have these long warp points from one end to another of the galaxy. If we can have some means to "rearrange" selected branches to pass on top of systems circles or elements and not underneath, then this will already be a possibility (it will require for them to be of a darker/lighter colour though). I do know there is something going on there, because I noticed that intersection pass over other intersections with a discovery priority? Basically, they do not exist in the same layer. You can notice that when you build gates and the line becomes orange, and by using Skoormit map it becomes evident. Some goes on top some others below. Perhaps there may be space for layer optimization here as well, helping with performance opening large maps. Am I correct? If not scrap it.

Eventually, the branch could have a selection and a toggle called long connection, which will make that particular branch of a different colour if selected. I don't know, perhaps red and pink if gate connected.

While at it, and I know it is a pain, Zoom and grid size selection features back will be highly appreciated

There is always the good old don't touch it if not broken approach.

I always aim to minimize the number of intersecting JP paths, but there's only so much you can do.

See the attached for some suggestions. After you do those, you might notice some further easy adjustments.

Don't worry: the longer your game goes, the more fun it gets. See the other attached for an example.

Those suggestions look good - as you say, they should at least reduce the overlap.

I don't know if I could stand playing with the way you've got your map setup - too many long connections cutting across the entire map; like the Afbull connection to whatever system you've got just offscreen to the top left, or the Aha system connecting to AKA in the top left and way off down the bottom left. Unfortunately, there's just not much to be done with what we've got - I suspect we'd need an actual 3d grid to make sense of it all.

Maybe it's me, but I cannot find a way to promote the civilian administrators.
I need a planetary admin of level x, but the ones at level x-1 have better parameters and I don't find how to promote them.

As far as I know (and this could well be wrong), they'll naturally self-promote as long as there are free governorships of a higher level available; it just might take some time. I think there's a way to force-promote them if you turn on SM mode.

Wow lots to digest here, in no particular order:

I think this is too complicated. We currently have a grand total of seven ground unit types, adding several more just for aircraft seems rather awkward. I would also suggest that it is unnecessary, and an easier approach would be to simply model air units as a capability which can be applied to any vehicle type, conferring (say) 2x size, 2x GSP, 0.5x HP, and 0.5x armor multipliers in exchange for using the air combat mechanics instead of normal ground combat mechanics. I would prefer this approach as it keeps the ground units UI simple while allowing for a lot of roleplay freedom - for example, having an armor multiplier means I could use a VEH base type and choose between light armor for 'normal' warplanes and medium armor for my A-10 Warthog equivalents. On the other hand, designing a UHV with flight capability to model a massive hovering skybase sort of aircraft is very fitting for some settings.

Using the existing unit types as the basis also means the question of weaponry is cleared up as well, and personally I see no reason to add weapon restrictions and restrict roleplay - heavier weapons are generally more specialized anyways, so I doubt we're opening up some silly exploit involving UHV aircraft with 4x SHAV or something.
I'm not opposed to the idea of flight being a capability, I think what you suggest would be far more convoluted to implement as currently all capabilities only affect the To-Hit and Hit Chances when fighting in different terrain/environment (and boarding allowing a new "environment" which is kinda iffy as it only works for offense since all ground units work defensively on board). Adding new mechanics for size/GSP/HP multipliers I would think would be significantly more code intensive rather than adding new Base Unit Types. There's plenty of space in the Ground Unit Design window for 4 more.

Adding as a capability would seem the easiest, also give Infantry a "Jet Pack" option. 

Partially agreed on fortification, disagreed on terrain. I think aircraft should be able to benefit from terrain, it may not be the most "realistic" but I think a lot of headcanons imagine, say, aircraft sweeping around mountain peaks or skimming forests to fly beneath enemy radar before popping up to fire a torpedo down the exhaust port... or something more realistic.    Again, no need to restrict it here.

As far as fortification goes, I would say it can still apply when aircraft are the target of normal ground unit fire - representing them being caught at base in a hangar, surely an airbase can be fortified to some degree? Of course, fortification should not apply when facing AA fire during the AA fire phase.
Valid points, I could concede on my suggestion for the permanent hidden aircraft capability reducing the terrain factor rather than negating it outright. And while I understand the want to have aircraft protected in hangars able to be fortified, again in headcannons, you may also have to worry about your actual runways being damaged and not all your aircraft being stowed away at the same time. I think its a good trade off with aircraft essentially being glass cannons for all intents and purposes

Terrain modifiers being ignored or amplified would be most appropriate.  Air units have trouble seeing/attacking folks in dense forest and in caves, pretty easy time for those out in the open.

In order for an airbase to have appreciable fortification, it must cost something.  It's just not the planes, its the ordance, fuel, parts, etc that are about.  At a bare minimum, it should cost TIME to DEPLOY, so they provide nothing to damage output of the unit until X number of ticks, with the X being reliant upon the fortification level.  Overall, these assets should be in the way back with the STO's and have no need for fortification.  For Jump Infantry, they get could get a modifier/perk which ignores this, or reduces it.

There is no practical way of fortifying an airbase in today's world, versus trenchworks, pillboxes, and Hesco walls. (Encircling an airbase with any does little to nothing to protect it from air/arty attack.

One thing that perhaps is being overlooked, why not simply have a tech which allows for pure ground based fighters, which would have a base defense characteristic based upon engine tech, and then an inverse relationship with anything added to it, with LAA and no armour being the baseline of zero, and then an inverse relationship between defense proportional with added/reduced weight.