I have been implementing this satellite and orbit toy. The journey has been fun so far, but the next topic... I need to take care of time now.
Oh Gods and JPL and other higher beings you might pray to.
Time zones are fun, right? I don't really care about them though. UTC solves a lot of problems in that regard.
So: UTC is actually just the naming of seconds from the TAI - International atomic Time. Naming means "this second is this year, month, hour, minute, second" - basically transforming some arbitrary number of seconds since some arbitrary point in time into a date.
Of course, we are tying UTC to earths rotations, and earth doesn't rotate perfectly. However, UTC needs to align with the rotation so that day/night etc are correct. Leap seconds solve the offset this causes - and are the bane of many people working with time.
But with knowing all past leaps you can perfectly correlate UTC and TAI - for the past. So looking at the past is neat and doable and yay. It goes to shit for the future though, as leap seconds are only know half a year or so in advance. RIP. You actually cannot say how many seconds are between now and UTC 2065-01-01!
So in space things you want to get rid of these little leaps, and you also might want something that is more aligned to everything in the solar system. So they came up with Barycentric Dynamic Time (TDB) and Terrestrial Time (TT). TDB is basically a virtual clock running in the barycenter of the solar system.
For near earth observations, one uses Terrestrial Time however(TT). Which is easy: the same as TAI, but with +32.184 seconds, cause why not!
TT and TBD are not the same, only almost. Cause relativistic effects (Thanks Einstein). They "run at different speeds at different times of the year"! FUN!
The formula for them states that
TDB - TT = K * sin (E)where K is some(argh) constant and E is the eccentric anomaly of the Earth-Moon-Barycenter around the Solar-System-Barycenter. Im not going further, on this, there is an API that does this for you and thank the lords and ladies at JPL for that.
You also need an epoch! -nix people know epochs well - 1970-01-01 is where you count seconds from. In Space things people use the J2000 epoch - "roughly noon on January first, 2000". Depending on what you do, you then feed in seconds or fractional days since that epoch into the APIs and math you need.
Oh, and the actual J2000 epoch isn't at noon, but 11:59:27.816(thanks Wikipedia) in TAI (whatever that is in UTC, leap seconds yay). Counting from J2000 is done using Julian days, which are 86400 seconds. These can be counted in different time systems. JDTDB, JDUTC, JDTDT. You probably want JDTDB (steady, no leap seconds, solar system barycenter), but its easy to end up with JDUTC when naively calculating using UTC since J2000. JDUTC also gets a little weird with leap seconds again, so lets just stay in TAI or TT or TDB.
Last but not least: spacecraft time. I probably can get away with letting NASA SPICE handle this completely. Otherwise this will be another interesting topic (please no).
So yeah, time is fun. I most likely understood something wrong and will implement my side of it as such. And notice down the line, due to things being weirdly off, and I will search for the cause of the issues forever.
Why am I doing this project again?
Source on all this: https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/time.html
EDIT 1: Changed dates into iso. Oops Thanks u/cearrach for pointing that out.