GCAT: General Catalog of Artificial Space Objects

Jonathan C. McDowell

Definitions

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:


Here are a selection of valid Vague Date strings and their mapping to a date confidence interval.


PrecisionVague DateRange implied (semi-open interval)Width
Millisec2016 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
Centiday2016 Jun 8.98 2016 Jun 8 2331:12 to Jun 8 2345:36 0.01d
Centidays2016 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 00003d
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
Quarters2016 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
Centuries21C? 1901 Jan 1 0000 to 2201 Jan 1 0000 300y
Millenium3M 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.)