GCAT: General Catalog of Artificial Space Objects

Time Representations and Vague Date Format

Time Scales

All dates in GCAT are at least nominally in Coordinated Universal Time (UTC). Comparing launches and orbital events occuring across the world requires a global timescale - local time zones are useless. UTC, like local times, has the bad feature that it is not continuous - there are occasional leap seconds.

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.

Julian Date

We can express dates numerically using the Julian Date (JD). The JD day number is a continuous count of days starting at noon UTC on BC 4713 Jan 1 Old Style/Julian calendar, which is noon UTC on BC 4714 Nov 24 New Style/Gregorian calendar.

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.

Vague Date Format

Dates in the General Catalog are usually recorded as strings in what I call the 'Vague Date' format. A Vague Date string defines a time range within which an event is believed to lie.

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.345

which 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:

• Domain, consisting of the string AD or BC. This is usually omitted and the value AD is assumed. Of course, we don't normally need BC for space events! But I use the same format for astronomy, where we do have observations of supernovae and comets before 1 AD.

  
  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).

• Year field.

  
  This can be either:

  • The (Gregorian) year, as an integer; or
  • A century descriptor, format: integer followed by letter. The letter can be C or M for century or millenium. For example, 20C means between 1901 Jan 1 and 2001 Jan 1; M indicates a millenium; 3M means between 2001 Jan 1 and 3001 Jan 1. Usually for astronautical applications we know the date more accurately than a century!
• Month (generalized month), consisting of the (case sensitive) strings Jan, Feb, .... Dec, and the special strings Q1, Q2, Q3, Q4 indicating the year-quarters Jan-Mar, Apr-Jun, Jul-Sep, Oct-Dec respectively.
• Day, an integer in the range 1, 31 always right justfied in a two byte field.
• Time, in one of two formats:
• Centiday: A day decimal fraction with one or two significant digits. This format was used by the RAE table of Earth Satellites and related satellite tabulations.
• HMS: A time in the format hhmm:ss.sss (where trailing items can be omitted) parsed as:
  • The hour, 00 to 24 (leading zeroes required)
  • Minute, 00 to 60 (leading zeroes required), appended to the hour value without any separator.
  • Second, 00 to 60 (leading zeroes required), appended to the minutes with a colon separator.
  • Millisecond, 000 to 999, appended to the seconds with a decimal point
• Schedule flag, an optional trailing 's' to indicate a scheduled date, where the
• Flag, An optional trailing question mark to indicate uncertainty.

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:12 to Jun 8 2345:36	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.)