An even better choice of timescale would be a continuous one, such as TT, TDB or TCB. JPL Horizons data is expressed in TDB, but most data in the space community is in UTC, and (at least for this release) I have relunctantly decided to go with the crowd.
Nontechnical readers may be more familiar with UTC by the essentially equivalent name GMT (Greenwich Mean Time). The US military tags time zones with the phonetic alphabet, with UTC/GMT as zone 24 known as Z (Zulu) time.
Note, however that UTC is not a time zone per se - it is not restricted to a particular range of longitudes; and of course, it never has daylight savings time.
Times within a day are expressed as decimal days. Remember that the JD always starts at noon. For example, 0600 UTC on 2020 Aug 1 is JD 2459062.7500; 1800 UTC on 2020 Aug 1 is JD JD 2459063.2500.
Note that 12:00 UTC on Jan 1, 2000 is JD 2451545.0. This special epoch is the fundamental epoch of modern astronomy, known as J2000.0 for short.
Estimated launch times of rockets are provided as JD values to make it easy to sort the data and carry out computations. However, some launch times are uncertain - even only known to the nearest year or so. This uncertainty is incorporated in a human-readable date field that uses what I call the Vague Date Format, defined in the next section.
Many astronautical databases include dates which are actually approximate but are given as if they are precise. For example, a rocket which is only known to have launched sometime in 1984 may be entered with a date of 1984 Jan 1 0000:00 as if it was known to the nearest second. This is particularly common if the date is stored as a single real number (e.g. Julian Day value).
To fix this, every date field should actually be a pair of values - either two dates as a confidence interval or a date and an uncertainty value. This adds storage, maintenance and I/O software overhead to the handling of dates.
As a compromise between this additional overhead and following the common practice of ignoring the problem, the Vague Date string format translates to a time confidence interval with a particular precision. A maximal-precision Vague Date is of the form
2016 Jun 8 2359:57.345which is interpreted as UTC in a geocenter-fixed frame, lying in the millisecond between 2359:57.3450 and 2359:57.3460 UTC. Note that there must be two spaces between "Jun" and "8" here.
We provide the ability to encode greater uncertainty by allowing rightmost fields to be omitted, and optionally a question mark symbol to be appended.
In the General Catalog we only allow 1 second precision, so e.g.
2016 Jun 8 2359:57
The full specification of the format is as a series of fields increasing in precision from left to right, with a possible question-mark suffix. The only mandatory field is the year, but if a field is present so must all the fields to the left of it, except for the optional leftmost 'domain' field.
The fields are:
It's true that nowadays academic historians would advocate using the 'common era' designations CE and BCE to avoid Christian associations, but, having grown up with BC and AD, I find this overly precious despite my atheism - if you are going to worry about that, perhaps you should change the zero point (to the Space Era of 1957, for example).
This can be either:
Here are a selection of valid Vague Date strings and their mapping to a date confidence interval.
|Precision||Vague Date||Range implied (semi-open interval)||Width|
|Millisec||2016 Jun 8 2355:57.345||2016 Jun 8 2355:57.345 to 57.346||1ms|
|Second||2016 Jun 8 2355:57||2016 Jun 8 2355:57.0 to 2355:58.0||1s|
|Seconds||2016 Jun 8 2355:57?||2016 Jun 8 2355:56.0 to 2355:59.0||3s|
|Minute||2016 Jun 8 2355||2016 Jun 8 2355:00 to 2356:00||1m|
|Minutes||2016 Jun 8 2355?||2016 Jun 8 2354:00 to 2357:00||3m|
|Centiday||2016 Jun 8.98||2016 Jun 8 2331:48 to Jun 8 2345:54||0.01d|
|Centidays||2016 Jun 8.98?||2016 Jun 8 2316:48 to Jun 9 0000:00||0.03d|
|Hour||2016 Jun 8 23h||2016 Jun 8 2300:00 to Jun 9 0000:00||1h|
|Hours||2016 Jun 8.9||2016 Jun 8 2136:00 to Jun 9 0000:00||2.4h|
|Day||2016 Jun 8||2016 Jun 8 0000 to 2016 Jun 9 0000||1d|
|Day (scheduled)||2016 Jun 8s||2016 Jun 8 0000 to 2016 Jun 9 0000||1d|
|Days||2016 Jun 8?||2016 Jun 7 0000 to 2016 Jun 10 0000||3d|
|Month||2016 Jun||2016 Jun 1 0000 to 2016 Jul 1 0000||1mo|
|Months||2016 Jun?||2016 May 1 0000 to 2016 Aug 1 0000||3mo|
|Quarter||2016 Q2||2016 Apr 1 0000 to 2016 Jul 1 0000||3mo|
|Quarters||2016 Q2?||2016 Jan 1 0000 to 2016 Oct 1 0000||9mo|
|Year||2016||2016 Jan 1 0000 to 2017 Jan 1 0000||1y|
|Years||2016?||2015 Jan 1 0000 to 2018 Jan 1 0000||3y|
|Decade||2010s||2010 Jan 1 0000 to 2020 Jan 1 0000||10y|
|Decades||2010s?||2000 Jan 1 0000 to 2030 Jan 1 0000||30y|
|Century||21C||2001 Jan 1 0000 to 2101 Jan 1 0000||100y|
|Centuries||21C?||1901 Jan 1 0000 to 2201 Jan 1 0000||300y|
|Millenium||3M||2001 Jan 1 0000 to 3001 Jan 1 0000||1000y|
|Millenia||3M?||1001 Jan 1 0000 to 4001 Jan 1 0000||3000y|
Some additional special values:
|Unknown||?||Date entirely unknown|
|Current||*||Now (for an end date, indicating still active, etc.)|