Subject: CCSDS standard

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 8 Jul 1996 16:05:25 GMT

I've talked about the CCSDS standard several times.  Here's a copy of the
relevant text concerning calendar date formats.  This is the only ASCII format
the standard discusses--the remainder are all various binary formats.

Bill Thompson

===============================================================================
                  CCSDS RECOMMENDATION FOR TIME CODE FORMATS

2.5 CCSDS ASCII CALENDAR SEGMENTED TIME CODE (ASCII)

2.5.1 T-FIELD

The CCSDS ASCII segmented time code is composed of a variable number of ASCII
characters forming the T-field.

Both ASCII time code variations are UTC-based and leap second corrections must
be made. The time represented is intended to match civil time usage.
Therefore, the epoch is taken to be the usual Gregorian calendar epoch of 1 AD,
and the time is that of the prime meridian.

The ASCII time code Recommendations are Level 1 time code formats.

2.5.1.1 ASCII TIME CODE A, Month/Day of Month Calendar Variation:

The format for ASCII Time Code A is as follows:

        YYYY-MM-DDThh:mm:ss.d->dZ

where each character is an ASCII character using one octet with the following
meanings:

        YYYY    =       Year in four-character subfield with values 0001-9999
          MM    =       Month in two-character subfield with values 01-12
          DD    =       Day of month in two-character subfield with values 01-28,
                        -29, -30, or -31
         "T"    =       Calendar-Time separator
          hh    =       Hour in two-character subfield with values 00-23
          mm    =       Minute in two-character subfield with values 00-59
          ss    =       Second in two-character subfield with values 00-59
                        (-58 or -60 during leap seconds)
        d->d    =       Decimal fraction of second in one- to n-character
                        subfield where each d has values 0-9
         "Z"    =       time code terminator (optional)

Note that the hyphen (-), colon (:), letter "T" and period (.) are used as
specific subfield separators, and that all subfields must include leading
zeros.

As many "d" characters to the right of the period as required may be used to
obtain the required precision.

An optional terminator consisting of the ASCII character "Z" may be placed at
the end of the time code.

EXAMPLE: 1988-01-18T17:20:43.123456Z

2.5.1.2 ASCII TIME CODE B, Year/Day of Year Calendar Variation:

The format for ASCII Time Code B is as follows:

        YYYY-DDDThh:mm:ss.d->dZ

where each character is an ASCII character using one octet with the following
meanings:

        YYYY    =       Year in four-character subfield with values 0001-9999
         DDD    =       Day of year in three-character subfield with values
                        001-365 or -366
         "T"    =       Calendar-Time separator
          HH    =       Hour in two-character subfield with values 00-23
          MM    =       Minute in two-character subfield with values 00-59
          SS    =       Second in two-character subfield with values 00-59
                        (-58 or -60 during leap seconds)
        d->d    =       Decimal fraction of second in one- to n-character
                        subfield where each d has values 0-9
         "Z"    =       time code terminator (optional)

Note that the hyphen (-), colon (:), letter "T" and period (.) are used as
specific subfield separators, and that all subfields must include leading
zeros.

As many "d" characters to the right of the period as required may be used to
obtain the required precision.

An optional terminator consisting of the ASCII character "Z" may be placed at
the end of the time code.

EXAMPLE: 1988-018T17:20:43.123456Z

2.5.1.3 SUBSETS OF THE COMPLETE TIME CODES:

When it is desired to use SUBSETS of each of the TWO ASCII time code format
variations described above, the following rules must be observed:

        a. The "calendar" subset (all subfields to the left of the "T") and the
        "time" subset (all subfields to the right of the "T") may be used
        independently as separate "calendar" or "time" formats, provided the
        context in which each subset is used makes its interpretation
        unambiguous.

        b. When calendar or time subsets are used alone, the "T" separator is
        omitted.

        c. Calendar or time subsets may contain all the defined subfields, or
        may be abbreviated to the span of interest by deleting the unneeded
        subfields, either on the left or on the right.  However, when subfields
        are deleted on the LEFT, all separators that had delimited the deleted
        subfields must be retained (except for the "T" which, by rule b, is
        dropped if the subset is used alone.) When subfields are deleted on the
        RIGHT, the separators that had delimited the deleted subfields are
        dropped.

        d. Subsets may NOT consist of partial subfields (e.g., must use "ss",
        not "s"). In particular, consistent use of the complete four-character
        YYYY subfield is required (e.g., "1989" instead of "89") because of the
        need to accommodate the upcoming century rollover in only 1 1 years.
        Note, however, that each fractional second ("d" character) is
        considered to be a complete subfield, and so any number of fractional
        seconds may be used.

        e. If calendar and time SUBSETS are then brought together to form a
        single time code format (joined with the "T" separator) the CALENDAR
        subset may NOT have been truncated from the RIGHT,.and the TIME subset
        may NOT have been truncated from the LEFT. That is, the format must be
        integral around the "T".

        f. Standardization on the use of these time code formats for purposes
        OTHER than identifying an instant of calendar or time in UTC (e.g.,
        unconventional use as a counter or tool for measuring arbitrary
        intervals) is not recommended. It is felt such a specialized
        application can best be viewed not as a time code format but rather as
        an engineering measurement format. Any such application of these time
        code formats is considered beyond the scope of this recommendation.

---

From: sla at umbra.ucolick.org (Steve Allen)
Date: 9 Jul 1996 06:31:46 GMT

In article <4rrbk5$qi2 at post.gsfc.nasa.gov>,

>        YYYY    =       Year in four-character subfield with values 0001-9999

Looks remarkably similar to ISO.

For the sake of FITS I would prefer it if we broadened the year
definition such that it was not restricted to 4-digit positive
integers 1-9999.  Even though the possibility raises other issues
(that would need eventual resolution) non-positive years and years
greater than 9999 should be permitted.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     FAX: +1 408 454 9863
WWW: http://www.ucolick.org/~sla                PGP public keys:  see WWW

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 9 Jul 1996 17:17:54 GMT

>Looks remarkably similar to ISO.

As I said, the CCSDS standard is a subset of ISO-8601.

Bill Thompson