🚀 go-pugleaf

cflatter@nrao.edu (Chris Flatters) writes:
>Dates in FITS are stored using two digits for the year.  Has anyone thought
>about what happens in 2000?

Sure; dates show up as 01/01/00, for example.  Personally, my software is
designed to interpret a two-digit date between 1970 and 2069; considering
this site was built in 1969, it seemed a reasonable choice.  You could, of
course, choose a different start date.  Eventually, it will break, but I
suspect it will be obsolete before then.

-G.
******************************************************************************
Glenn Eychaner, Big Bear Solar Observatory, California Institute of Technology
NSI/DECnet: SUNCUB::EYCHANER        Internet: eychaner@suncub.bbso.caltech.edu
USmail: 40386 North Shore Lane                eychaner_g@caltech.edu
        Big Bear City, CA  92314    Phone: (714) 866-5791 or (818) 356-4014
                                           (909) after November 14, 1992

In article <1992Aug26.231536.5504@nrao.edu>, cflatter@nrao.edu writes...
>Dates in FITS are stored using two digits for the year.  Has anyone thought
>about what happens in 2000?
> 
>	Chris Flatters
>	cflatter@nrao.edu

I've been looking into this for the SOHO program.  Currently, I've been looking
into a CCSDS standard "Time Code Formats" CCSDS 301.0-B-2.  I believe this is
also an ISO standard, but the number eludes me right now.  Basically, the
standard allows you to enter dates in the form, e.g.

			    1992-08-27T10:03:38.123

There's also an alternate form that allows you to use day-of-year rather than
month and day.  Either the date or time part can be left out, in which case the
"T" separater is omitted.  The fractional seconds is optional, and can be to
any precision desired.

Although I like FITS, and plan to use it, I find the eight character limit very
constraining.  As one person I work with said, "It's like programming in
FORTRAN 2".

Bill Thompson

In article <27AUG199210071784@stars.gsfc.nasa.gov>, thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes:
|> Although I like FITS, and plan to use it, I find the eight character limit very
|> constraining.  As one person I work with said, "It's like programming in
|> FORTRAN 2".

And we're all the way up to FORTRAN 77, with 90 due out RSN <grin>.

Seriously, though, it's supposed to be that way - maximum portability
and all that...

-- 
----------------------------------------------------------------------------
-- Archie Warnock                   Internet:  warnock@hypatia.gsfc.nasa.gov
-- Hughes STX                       "Unix --- JCL For The 90s"
-- NASA/GSFC                        

In article <27AUG199210071784@stars.gsfc.nasa.gov>, I wrote ...

>In article <1992Aug26.231536.5504@nrao.edu>, cflatter@nrao.edu writes...
>>Dates in FITS are stored using two digits for the year.  Has anyone thought
>>about what happens in 2000?
>> 
>>	Chris Flatters
>>	cflatter@nrao.edu
> 
>I've been looking into this for the SOHO program.  Currently, I've been
>looking into a CCSDS standard "Time Code Formats" CCSDS 301.0-B-2.  I believe
>this is also an ISO standard, but the number eludes me right now.  ...

I found my reference.  I believe that the CCSDS standard mentioned above also
corresponds to ISO 8601, although I can't get a copy of that document.

I do include below the relevant passage from CCSDS 301.0-B-2.

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.


2.5.2 P-FIELD:

There is no P-field identifying the ASCII Time Code Formats. The P-field
information is implicit in the parsing of the ASCII time code.