From owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  2 09:42:04 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA18490; Tue, 2 Jul 1996 09:42:04 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id VAA15042; Mon, 1 Jul 1996 21:00:46 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA08320 for <fitsbits at fits>; Mon, 1 Jul 1996 21:00:42 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA14240; Mon, 1 Jul 96 21:00:39 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 1 Jul 1996 19:27:34 GMT
From: sla at umbra.ucolick.org (Steve Allen)
Message-Id: <4r98r6$e6r at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory, Santa Cruz
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!inXS.uu.net!newsxfer2.itd.umich.edu!agate!darkstar.UCSC.EDU!umbra.ucolick.org!sla
References: <4r19kv$d6f at infa.central.susx.ac.uk> <31D80C21.7662 at ast.cam.ac.uk>
Subject: Re: MJD - not acceptable according to IAU (?)
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <31D80C21.7662 at ast.cam.ac.uk>, Guy Rixon  <gtr at ast.cam.ac.uk> wrote:
[about MJD-OBS]
>            In fact it's  one of the few keywords that's unambiguous already
>without  needing an offical definition.

MJD is ambiguous by about a minute depending on whether you mean
ET, UT, TAI, or some other timescale.
--
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 owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  2 09:41:46 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA18484; Tue, 2 Jul 1996 09:41:46 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id SAA13533; Mon, 1 Jul 1996 18:40:52 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id SAA07437 for <fitsbits at fits>; Mon, 1 Jul 1996 18:40:46 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA09403; Mon, 1 Jul 96 18:40:41 EDT
To: fitsbits at fits.cv.nrao.edu
Date: Mon, 01 Jul 1996 18:34:25 +0100
From: Guy Rixon <gtr at ast.cam.ac.uk>
Message-Id: <31D80C21.7662 at ast.cam.ac.uk>
Organization: Royal Greenwich Observatory
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!lll-winken.llnl.gov!enews.sgi.com!decwrl!olivea!spool.mu.edu!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news
References: <4r19kv$d6f at infa.central.susx.ac.uk>
Subject: Re: MJD - not acceptable according to IAU (?)
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Pierre Maxted wrote:
> 
> In article <4qroqt$7s4 at darkstar.UCSC.EDU>, Steve
> Allen <sla at umbra.ucolick.org> wrote:
> >Take note, however, of the WCS draft paper at
> >http://fits.cv.nrao.edu/documents/wcs/wcs.html
> >which proposes to standardize the usage of MJD-OBS.  This will work
> : : :
>  ... which reminds me that at the last IAU general meeting there was some
> discussion of abondoning MJD since it was ambiguous/redundant. Am I
> correct? Is it feasible to drop MJD from the FITS standard?

You can't drop something from the standard that isn't in yet.  Even if
MJD-OBS never becomes a mandatory part of the WCS extension to the FITS
standard, it's still valid as a general-purpose keyword  for observatories
to supply.  In fact it's  one of the few keywords that's unambiguous already
without  needing an offical definition.

-- 
Guy Rixon,				gtr at ast.cam.ac.uk 
Software Engineering Group,		Tel: +44-1223-374000
Royal Greenwich Observatory 		Fax: +44-1223-374700


From owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  2 10:16:54 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA18624; Tue, 2 Jul 1996 10:16:54 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id KAA18601; Tue, 2 Jul 1996 10:14:13 -0400
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id KAA13797 for <fitsbits at fits.cv.nrao.edu>; Tue, 2 Jul 1996 10:14:05 -0400 (EDT)
Received: from barnegat.gsfc.nasa.gov (barnegat.gsfc.nasa.gov [128.183.127.156]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id KAA07165 for <fitsbits at fits.cv.nrao.edu>; Tue, 2 Jul 1996 10:14:00 -0400 (EDT)
Received: from localhost by barnegat.gsfc.nasa.gov; (5.65/1.1.8.2/25Aug95-0336PM)
	id AA05913; Tue, 2 Jul 1996 10:12:44 -0400
Message-Id: <31D92E5B.41C6 at barnegat.gsfc.nasa.gov>
Date: Tue, 02 Jul 1996 10:12:43 -0400
From: Mike Corcoran <corcoran at barnegat.gsfc.nasa.gov>
X-Mailer: Mozilla 2.0 (X11; I; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: fitsbits at fits.cv.nrao.edu
Subject: Re: MJD - not acceptable according to IAU (?)
References: <4r19kv$d6f at infa.central.susx.ac.uk> <31D80C21.7662 at ast.cam.ac.uk> <4r98r6$e6r at darkstar.UCSC.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Steve Allen wrote:
> 
> In article <31D80C21.7662 at ast.cam.ac.uk>, Guy Rixon  <gtr at ast.cam.ac.uk> wrote:
> [about MJD-OBS]
> >            In fact it's  one of the few keywords that's unambiguous already
> >without  needing an offical definition.
> 
> MJD is ambiguous by about a minute depending on whether you mean
> ET, UT, TAI, or some other timescale.
> --
> 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

also, MJD-OBS, defined as the "date of the observation" is ambiguous by definition -
is this the start of the observation, the midpoint, etc?  This difference is
significant to the X-ray community, where a given image is generally composed of
individual segments obtained over an interval of many days.

Mike
-- 

***********************************************************
Dr. Michael F. Corcoran
High Energy Astrophysics Science Archive Research Center
Goddard Space Flight Center
Greenbelt, MD 20771
corcoran at barnegat.gsfc.nasa.gov
LHEAVX::CORCORAN
http://lheawww.gsfc.nasa.gov/users/corcoran/bio.html
***********************************************************


From owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  2 13:40:32 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA19496; Tue, 2 Jul 1996 13:40:32 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id MAA19360; Tue, 2 Jul 1996 12:54:37 -0400
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id MAA14973 for <fitsbits at fits.cv.nrao.edu>; Tue, 2 Jul 1996 12:54:33 -0400 (EDT)
Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id MAA09605 for <fitsbits at fits.cv.nrao.edu>; Tue, 2 Jul 1996 12:54:30 -0400 (EDT)
Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3)
	id SAA29212; Tue, 2 Jul 1996 18:47:07 +0200 (MET DST)
Message-Id: <199607021647.SAB09455 at ns2.hq.eso.org>
Received: from localhost.hq.eso.org by ns2.hq.eso.org with SMTP (8.7.5/ eso-5.3)
	id SAB09455; Tue, 2 Jul 1996 18:47:06 +0200 (MET DST)
To: fitsbits at fits.cv.nrao.edu
Cc: Peter Bunclark <psb at ast.cam.ac.uk>
Subject: Re: DATE-OBS='31/12/99' 
In-reply-to: Your message of "Fri, 28 Jun 96 15:21:55 BST."
             <31D3EA83.297F at ast.cam.ac.uk> 
Date: Tue, 02 Jul 1996 18:47:01 +0200
From: Preben Grosbol <pgrosbol at eso.org>
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Peter Bunclark wrote:

>In conclusion, we all agree there is a problem to be fixed, but not on
>much else.  I would like to add some further points:
>
>1) PAPER ONE did contain a few howlers (EPOCH being the most celebrated),
>   and so cannot be considered inviolate.  The phrase "the form 'dd/mm/yy'
>   (which is as good a system as any of the others)" is not only incredibly
>   flippant in the context, but quite inaccurate.  We've been discussing at
>   length the problem of a 2-digit year; also, the slashes are redundant, 
>   the day-month-year order is confusing to Americans (easily done),
>   and the order is little-endian.
>
>2) I would deprecate DATE-OBS from 1/1/2000; if FITS writers leave it out,
>   then old FITS readers won't misinterpret it.
>
>3) DATE-OBS = 'dd/mm/yyyy' is going to cause a lot of grief to old 
>   software.  And much of this old software is sitting on old systems
>   in operational situations and nobody dares touch it...
>
>4) I feel strongly the proposed new format should be most-significant
>   first;  it is convenient in many situations to be able to do a 
>   meaningful sort on the ascii collating sequence.
>
>5) I feel strongly about the FITS standard, despite its various shortcomings
>   (8-character keywords is my favourite, right up there with the lack
>   of an unsigned data-type).  However, we're about to write a new
>   FITS writer for a major observatory (ING La Palma) and will not 
>   let it out with the century ambiguity outstanding; any chance
>   of reaching a consensus here?

 I generally agree with these conclusions.  To narrow down the
options, the two main ones are:

 1) Patch up the 'DATExxxx' keyword definition in some way e.g. redefine
    the date value string, add extra keyword, ...

 2) Deprecate the usage of 'DATExxxx' after 1/1/2000 (Peter's #2)
    and replace it e.g. use 'MJD-xxxx' or a new set of keywords.

 Whatever 'patch up' one proposes there will be lots of problems.
Thus, I would favor the cleaner option namely #2. For readability,
I still support to have something else than 'MJD-xxxx'. Jonathen
suggested 'CALEN-' which unfortunately is at least one character
too long and 'CAL-xxxx'/'CALE-xxx' do not look as nice.  As one
more probably would use UT as reference, a 'UTC-xxxx' set of
keywords could be considered using the complete extended date/time
format of ISO 8601 for the date value string.

 I finally got the ISO8601:1988/1991 standard document. It defines
several formats but the most relevant is the 'Calendar date' 
(ref. 5.2.1) and the 'Combibations of date and time of day
representations' (ref.5.4.1). The complete representations are:

                            Basic               Extended
   Date format             ccyymmdd            ccyy-mm-dd
   date example            20100213            2010-02-13

   Date/time (UTC)format   ccyymmddThhmmss.sZ  ccyy-mm-ddThh:mm:ss.sZ
   date/time example       20100213T135310.3Z  2010-02-13T13:53:10.3Z

(Actually comma (,) is prefered by ISO but full stop (.) is allowed).
Due to readability the extended format would be prefered.  The
ISO standard also define formats for local time and periods of time.

 On the MJD-OBS issue, the latest WCS proposal I have seen specifies
TAI but leaves the definition of start/mean/end/... open since WCS
only need a mean epoch.  Partly due to the year 2000 issue, ESO is
internally using MJD-OBS instead of DATE-OBS.
 At the IAU I understood (maybe wrongly) that the main reason to deprecate
the MJD was that a number of variable star people did (could) not
read the definition of MJD and therefore sometimes forgot to correct
for the half day offset with respect to JD.  The proposed usage of
MJD in FITS is well defined and in agreement with the IAU definition.
One reason to use MJD rather than JD is the two extra digits it gives
which translates to an accuracy better than a millisecond for a 64-bit
IEEE floating point number.

Preben Grosbol


From owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  2 14:42:44 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA19751; Tue, 2 Jul 1996 14:42:44 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA19732; Tue, 2 Jul 1996 14:36:50 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA15722 for <fitsbits at fits>; Tue, 2 Jul 1996 14:36:40 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA17487; Tue, 2 Jul 96 14:36:36 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 02 Jul 1996 18:36:26 GMT
From: dwells at nrao.edu (Don Wells)
Message-Id: <DWELLS.96Jul2143626 at fits.cv.nrao.edu>
Organization: nrao
Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells
References: <199607021647.SAB09455 at ns2.hq.eso.org>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

"PG" == Preben Grosbol <pgrosbol at eso.org> writes:
PG>  I finally got the ISO8601:1988/1991 standard document. It defines
PG> several formats but the most relevant is the 'Calendar date' 
PG> (ref. 5.2.1) and the 'Combibations of date and time of day
PG> representations' (ref.5.4.1)..

A summary of ISO8601 is available at:
http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html

A URL for the subject line of this thread is at:
http://www.year2000.com/cgi-bin/clock.cgi
--
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
                    http://fits.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA


From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul  3 09:53:46 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA25082; Wed, 3 Jul 1996 09:53:46 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id SAA21127; Tue, 2 Jul 1996 18:27:29 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id SAA17485 for <fitsbits at fits>; Tue, 2 Jul 1996 18:27:18 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA26613; Tue, 2 Jul 96 18:27:11 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 2 Jul 1996 17:36:27 GMT
From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Message-Id: <4rbmmr$4g7 at post.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!interpath!news.sprintlink.net!news-fw-12.sprintlink.net!news.sprintlink.net!news-fw-6.sprintlink.net!news.ultranet.com!homer.alpha.net!uwm.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!lerc.nasa.gov!purdue!ames!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson
References: <31CE980A.319B at ast.cam.ac.uk> <31D0FC80.BB8 at ast.cam.ac.uk> <4qrl92$r5q at noao.edu>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

seaman at noao.edu (Rob Seaman) writes:

>Peter Bunclark wrote:

>> What is happening about the millenium?  Is there any proposed way of
>> dealing with the 2-digit original spec. of the year of observation.

>Previous discussion has centered on related issues within the WCS
>proposal.  Looking back through the half dozen or so messages that
>mention DATE-OBS, I see these keywords mentioned:

>	MJD-OBS MJD-REF MJD-BEG MJD-AVG MJD-END MJD-WCS
>	DATE-OBS TIME-OBS DATE-END TIME-END TIMEUNIT
>	TIMESYS TIMEREF
>	OBT_TIME
>	DATE_OBS = 1995-11-16T21:21:15.721Z

>(The DATE_OBS format is stated to agree with ISO 8601 as endorsed by
>some group called the "Consultative Committee for Space Data Systems".)

Looking up the membership of the Consultative Committe mentioned above, I find
the following member Agencies:

	British National Space Centre (BNSC) / United Kingdom
	Canadian Space Agency (CSA) / Canada
	Centre National D'Etudes Spatiales (CNES) / France
	Deutsche Forschungsanstalt fur Luft und Raumfahrt (DLR) / FRG
	European Space Agency (ESA) / Europe
	Instituo de Pesquisas Espaciais (INPE) / Brazil
	National Aeronautics and Space Administration (NASA) ? USA
	National Space Development Agency of Japan (NASDA) / Japan

and the following "observer" Agencies

	Centro Technico Aeroespacial (CTA) / Brazil
	Department of Communication/Communications Research Centre (DOC/CRC) /
		Canada
	Institute for Space Astronautics and Science (ISAS) / Japan.

Fairly impressive group.  Their address is 

	CCSDS Secretariat
	Communications and Data Systems Division (Code-OS)
	National Aeronautics and Space Administration
	Washington, DC 20546, USA

Bill Thompson


From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul  3 09:54:14 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA25088; Wed, 3 Jul 1996 09:54:14 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id SAA21366; Tue, 2 Jul 1996 18:44:11 -0400
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id SAA17615 for <fitsbits at fits.cv.nrao.edu>; Tue, 2 Jul 1996 18:44:04 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id SAA18245 for <fitsbits at fits.cv.nrao.edu>; Tue, 2 Jul 1996 18:44:00 -0400 (EDT)
Received: (from pence at localhost) by tetra.gsfc.nasa.gov (LHEA9504/950407.s1) id SAA01439; Tue, 2 Jul 1996 18:42:45 -0400
Date: Tue, 2 Jul 1996 18:42:45 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Message-Id: <199607022242.SAA01439 at tetra.gsfc.nasa.gov>
To: fitsbits at fits.cv.nrao.edu
Subject: Re: DATE-OBS='31/12/99'
Cc: pence at tetra.gsfc.nasa.gov
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Regarding how to fix the DATE-OBS problem, I support Rob Seaman's point
of view of extending the definition of the existing DATE-OBS keyword,
rather than deprecating the keyword and replacing it with an entirely
new one.  The main reason for this is that I think this is the cleanest
and most elegant solution and will also require the least amount of
effort for the FITS community to retrofit existing FITS readers.
Regardless of what solution is finally adopted, *all* existing FITS
software that reads the DATE-OBS (and DATE-END) keyword will have to be
modified.  It will be simpler to add more code to parse a more extended
DATE-OBS keyword format than it will be to add code to read and parse
an entirely new keyword if it does not find the DATE-OBS keyword in the
header.

I would go further than Rob, however, and suggest that we extend the
definition of DATE-OBS keyword to allow the full ISO 8601 data/time format,
in addition to the current dd/mm/yy format.  Thus all the following
examples would be legal:

     DATE-OBS= '24/06/98' 
     DATE-OBS= '2010-02-13T13:53:10.3Z' 
     DATE-OBS= '2010-02-13'

The FITS reading software can easily distinguish between the old and
new formats.  This does not invalidate any existing FITS files, so it
does not violate the 'once FITS always FITS' rule.  Also, this will not
'trick' any existing FITS readers into interpreting the wrong date
(which is one of the main drawbacks to the proposal to use a
'dd/mm/yyyy' format). 

This solution avoids the need to invent a new class of UTC-xxxx or
CAL-xxxx keywords.  It also eliminates the problem of deciding which
keyword is dominant if a FITS file contained both.

Bill Pence
HEASARC/GSFC/NASA


From owner-fitsbits at tarsier.cv.nrao.edu  Fri Jul  5 08:29:16 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id IAA06271; Fri, 5 Jul 1996 08:29:16 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id VAA31010; Wed, 3 Jul 1996 21:25:19 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA29003 for <fitsbits at fits>; Wed, 3 Jul 1996 21:25:15 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA20885; Wed, 3 Jul 96 21:25:12 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 3 Jul 1996 15:15:00 GMT
From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Message-Id: <4re2pk$n7c at post.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!elroy.jpl.nasa.gov!swrinde!newsfeed.internetmci.com!news.mathworks.com!news2.cais.net!news.cais.net!info.usuhs.mil!cadig2.usna.navy.mil!cs.umd.edu!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson
References: <199607021647.SAB09455 at ns2.hq.eso.org>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Preben Grosbol <pgrosbol at eso.org> writes:

	(stuff deleted)

> I finally got the ISO8601:1988/1991 standard document. It defines
>several formats but the most relevant is the 'Calendar date' 
>(ref. 5.2.1) and the 'Combibations of date and time of day
>representations' (ref.5.4.1). The complete representations are:

>                            Basic               Extended
>   Date format             ccyymmdd            ccyy-mm-dd
>   date example            20100213            2010-02-13

>   Date/time (UTC)format   ccyymmddThhmmss.sZ  ccyy-mm-ddThh:mm:ss.sZ
>   date/time example       20100213T135310.3Z  2010-02-13T13:53:10.3Z

>(Actually comma (,) is prefered by ISO but full stop (.) is allowed).
>Due to readability the extended format would be prefered.  The
>ISO standard also define formats for local time and periods of time.

	(more stuff deleted)

I thank Preben Grosbol for his clear explanation of the ISO8601 format.  I
would just like to add that the seconds part of the standard can be extended to
an arbitrary number of significant digits.  For example

	2010-02-13T13:53:10Z
	2010-02-13T13:53:10.3Z
	2010-02-13T13:53:10.31Z
	2010-02-13T13:53:10.312Z
	etc.

Bill Thompson


From owner-fitsbits at tarsier.cv.nrao.edu  Fri Jul  5 08:29:44 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id IAA06277; Fri, 5 Jul 1996 08:29:44 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id EAA00754; Thu, 4 Jul 1996 04:36:08 -0400
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id EAA01928 for <fitsbits at fits.cv.nrao.edu>; Thu, 4 Jul 1996 04:36:04 -0400 (EDT)
Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id EAA11527 for <fitsbits at fits.cv.nrao.edu>; Thu, 4 Jul 1996 04:36:00 -0400 (EDT)
Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3)
	id KAA20500; Thu, 4 Jul 1996 10:34:32 +0200 (MET DST)
Message-Id: <199607040834.KAB05942 at ns2.hq.eso.org>
Received: from localhost.hq.eso.org by ns2.hq.eso.org with SMTP (8.7.5/ eso-5.3)
	id KAB05942; Thu, 4 Jul 1996 10:34:30 +0200 (MET DST)
To: fitsbits at fits.cv.nrao.edu
Cc: William Pence <pence at tetra.gsfc.nasa.gov>
Subject: Re: DATE-OBS='31/12/99' 
In-reply-to: Your message of "Tue, 02 Jul 96 18:42:45 EDT."
             <199607022242.SAA01439 at tetra.gsfc.nasa.gov> 
Date: Thu, 04 Jul 1996 10:34:28 +0200
From: Preben Grosbol <pgrosbol at serv2.hq.eso.org>
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

William Pence wrote:

>I would go further than Rob, however, and suggest that we extend the
>definition of DATE-OBS keyword to allow the full ISO 8601 data/time format,
>in addition to the current dd/mm/yy format.  Thus all the following
>examples would be legal:
>
>     DATE-OBS= '24/06/98' 
>     DATE-OBS= '2010-02-13T13:53:10.3Z' 
>     DATE-OBS= '2010-02-13'

 It seems clear that a new date format should use the ISO 8601 definition.
However, I am still concerned with old reader getting a new format in
the date value string. As a simple example here is a FORTRAN-77
program 

      PROGRAM DATEOBS
C
      INTEGER       IDD, IMM, IYY
      CHARACTER*80  CARD1, CARD2, CARD3
C
      CARD1 = 'DATE-OBS= ''24/06/98''                / FITS standard'
      CARD2 = 'DATE-OBS= ''2010-02-13''              / ISO date'
      CARD3 = 'DATE-OBS= ''2010-02-13T13:53:10.3Z''  / ISO date/time'
C
      WRITE(6,1000) CARD1
 1000 FORMAT(A72)
      READ(CARD1,500) IDD,IMM,IYY
 500  FORMAT(11X,I2,X,I2,X,I2)
      WRITE(6,1001) IYY,IMM,IDD
 1001 FORMAT('Year ',I2,', Month: ',I2,', Day: ',I2)
C
      WRITE(6,1000) CARD2
      READ(CARD2,500) IDD,IMM,IYY
      WRITE(6,1001) IYY,IMM,IDD
C
      WRITE(6,1000) CARD3
      READ(CARD3,500) IDD,IMM,IYY
      WRITE(6,1001) IYY,IMM,IDD
C
      END

which on a SunOS gives:

 ns2{~/tmp}223: f77 dateobs.for -o dateobs
 dateobs.for:
  MAIN dateobs:
 ns2{~/tmp}224: dateobs
 DATE-OBS= '24/06/98'                / FITS standard
 Year 98, Month:  6, Day: 24
 DATE-OBS= '2010-02-13'              / ISO date
 Year -2, Month:  0, Day: 20
 DATE-OBS= '2010-02-13T13:53:10.3Z'  / ISO date/time
 Year -2, Month:  0, Day: 20

 Although most FITS readers would be more clever there may still be
a few 'old' trivial programs left.

 It is clear that all major organizations will be able to implement
the change but there are also smaller sites.

Preben Grosbol


From owner-fitsbits at tarsier.cv.nrao.edu  Fri Jul  5 08:30:10 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id IAA06294; Fri, 5 Jul 1996 08:30:10 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id LAA01673; Thu, 4 Jul 1996 11:56:36 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id LAA04895 for <fitsbits at fits>; Thu, 4 Jul 1996 11:56:30 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA14406; Thu, 4 Jul 96 11:56:26 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 4 Jul 1996 07:22:48 +0200
From: pausch at electra.saaf.se (Paul Schlyter)
Message-Id: <4rfkf8$idg at electra.saaf.se>
Organization: Svensk Amat|rAstronomisk F|rening
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!jussieu.fr!oleane!tank.news.pipex.net!pipex!news.mathworks.com!nntp.primenet.com!news.cais.net!nntp.uio.no!news.kth.se!tybalt.admin.kth.se!merope.saaf.se!electra.saaf.se!not-for-mail
References: <4r19kv$d6f at infa.central.susx.ac.uk> <31D80C21.7662 at ast.cam.ac.uk> <4r98r6$e6r at darkstar.ucsc.edu>
Subject: Re: MJD - not acceptable according to IAU (?)
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <4r98r6$e6r at darkstar.ucsc.edu>,
Steve Allen <sla at umbra.ucolick.org> wrote:
 
> In article <31D80C21.7662 at ast.cam.ac.uk>, Guy Rixon  <gtr at ast.cam.ac.uk> wrote:
> [about MJD-OBS]
>> In fact it's  one of the few keywords that's unambiguous already
>> without  needing an offical definition.
> 
> MJD is ambiguous by about a minute depending on whether you mean
> ET, UT, TAI, or some other timescale.
 
I've never seen JD or MJD used with TAI as the fundamental time scale.
One implicitly assumes UT as the basic time scale, which still leads
to a small ambiguity of course since "UT" can be either of UTC, UT0,
UT1 or UT2.....
 
Astronomers sometimes use JD based on ET (nowadays TDT) -- to show
that, they talk about "JED" in such cases.
 
---------------------------------------------------------------------------
 
There are more serious ambuiguities involved here though.  MJD is
often used, by various people, as any day count, starting at any day
they feel is suitable.  And even JD is subject to this: the NORAD
people, who keep track of all our artificial satellites, have their
own definition of JD.  Today's date is 1996-07-03, let's assume it's
15:00 UT.  This will become:
 
   Astronomer's JD:  2450268.125
   NORAD "JD":           185.625
 
The NORAD "JD" is simply a count of the number of days into the year, and
it's reset to 1 at the beginning of each new year.
 
I once complained to T.S. Kelso (he's the one who use to post
satellite orbital elements in sci.space.news) about this usage of
"JD".  He responded that he understood my point of view, but that
this usage now is so widespread within NORAD that there's no hope in
changing it.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf.se        psr at home.ausys.se


From owner-fitsbits at tarsier.cv.nrao.edu  Fri Jul  5 08:30:51 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id IAA06310; Fri, 5 Jul 1996 08:30:51 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id NAA01855; Thu, 4 Jul 1996 13:26:49 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id NAA05507 for <fitsbits at fits>; Thu, 4 Jul 1996 13:26:43 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA18578; Thu, 4 Jul 96 13:26:41 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 4 Jul 1996 07:23:42 +0200
From: pausch at electra.saaf.se (Paul Schlyter)
Message-Id: <4rfkgu$ief at electra.saaf.se>
Organization: Svensk Amat|rAstronomisk F|rening
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!jussieu.fr!oleane!tank.news.pipex.net!pipex!news.mathworks.com!nntp.primenet.com!news.cais.net!nntp.uio.no!news.kth.se!tybalt.admin.kth.se!merope.saaf.se!electra.saaf.se!not-for-mail
References: <4r19kv$d6f at infa.central.susx.ac.uk> <31D80C21.7662 at ast.cam.ac.uk> <4r98r6$e6r at darkstar.UCSC.EDU> <31D92E5B.41C6 at barnegat.gsfc.nasa.gov>
Subject: Re: MJD - not acceptable according to IAU (?)
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <31D92E5B.41C6 at barnegat.gsfc.nasa.gov>,
Mike Corcoran  <corcoran at barnegat.gsfc.nasa.gov> wrote:
 
> Steve Allen wrote:
> 
>> In article <31D80C21.7662 at ast.cam.ac.uk>, Guy Rixon  <gtr at ast.cam.ac.uk> wrote:
>> [about MJD-OBS]
>>>  In fact it's  one of the few keywords that's unambiguous already
>>>  without  needing an offical definition.
>> 
>> MJD is ambiguous by about a minute depending on whether you mean
>> ET, UT, TAI, or some other timescale.
> 
> also, MJD-OBS, defined as the "date of the observation" is ambiguous by
> definition - is this the start of the observation, the midpoint, etc?
> This difference is significant to the X-ray community, where a given
> image is generally composed of individual segments obtained over an
> interval of many days.
 
And this ambiguity has nothing to do with MJD -- it'll still be there
if you use JD, ordinary calendar dates, number of seconds since
1970-01-01, or whatever.
 
If the duration of the observation becomes significant, information
about this must of course be included.  The appropriate action is
then to give "start of observation" and "end of observation" or
"duration of observation".  If the observation is stopped and
restarted repeatedly, this too may be insufficient - in such
cases one simply must supply enough details about the observation,
for instance time of each start and stop.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf.se        psr at home.ausys.se


From owner-fitsbits at tarsier.cv.nrao.edu  Sat Jul  6 14:57:31 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13936; Sat, 6 Jul 1996 14:57:31 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id IAA06369; Fri, 5 Jul 1996 08:47:40 -0400
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id IAA13502 for <fitsbits at fits.cv.nrao.edu>; Fri, 5 Jul 1996 08:47:37 -0400 (EDT)
Received: from poseidon.ifctr.mi.cnr.it (poseidon.ifctr.mi.cnr.it [155.253.2.87]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id IAA26285 for <fitsbits at fits.cv.nrao.edu>; Fri, 5 Jul 1996 08:42:50 -0400 (EDT)
Received: by poseidon.ifctr.mi.cnr.it (5.65/1.34)
	id AA17572; Fri, 5 Jul 1996 14:46:32 +0200
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
Date: Fri, 5 Jul 1996 14:46:31 +0200 (MET DST)
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Reply-To: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Subject: Re: MJD - not acceptable according to IAU (?)
To: fitsbits at fits.cv.nrao.edu
In-Reply-To: <4rfkf8$idg at electra.saaf.se>
Message-Id: <Pine.3.89.9607051404.S15993-0100000 at poseidon.ifctr.mi.cnr.it>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

On 4 Jul 1996, Paul Schlyter wrote:

> There are more serious ambuiguities involved here though.  MJD is
> often used, by various people, as any day count, starting at any day
> they feel is suitable.  And even JD is subject to this: the NORAD
> people, who keep track of all our artificial satellites, have their
> own definition of JD. 
  [...]
> The NORAD "JD" is simply a count of the number of days into the year, and
> it's reset to 1 at the beginning of each new year.

  I've often seen on various (non-astronomical) newsgroups people
  talking of "Julian Day number" as the number of days in the year.
  Since I think this is inexact and to be DEPRECATED, I usually respond
  to such pointing telling them that this is NOT JD (the 244.... thing)
  but should be called something else.

  It is true also that there are (or were) places using "their own"
  "M"JD (as days elapsed since a given date, not just subracting
  2400000.5), for instance I recall that some 10-12 years ago at the
  ESOC (European Space Operation Centre) they used an "MJD" which was
  in days elapsed since 0 UT of 1 Jan 1950   ... I recall a telex from
  a guy in Leicester telling them this was wrong, that they should use
  the (formerly IAU supported) MJD which "was used by astronomers
  throughout the civilised world and also in Leicester".
  [From this some humorous fellow scribbled below it "from which one
  infer Leicester is not part of the civilised world" :-) ]




From owner-fitsbits at tarsier.cv.nrao.edu  Sat Jul  6 14:58:32 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13951; Sat, 6 Jul 1996 14:58:32 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id PAA09736; Fri, 5 Jul 1996 15:44:52 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id PAA16519 for <fitsbits at fits>; Fri, 5 Jul 1996 15:44:47 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA09418; Fri, 5 Jul 96 15:44:44 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 5 Jul 1996 09:25 EDT
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger)
Message-Id: <5JUL199609253197 at nssdca.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger
References: <4r19kv$d6f at infa.central.susx.ac.uk> <31D80C21.7662 at ast.cam.ac.uk> <4r98r6$e6r at darkstar.ucsc.edu> <4rfkf8$idg at electra.saaf.se>
Subject: Re: MJD - not acceptable according to IAU (?)
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <4rfkf8$idg at electra.saaf.se>, pausch at electra.saaf.se (Paul Schlyter) writes...
> 
>the NORAD
>people, who keep track of all our artificial satellites, have their
>own definition of JD.  Today's date is 1996-07-03, let's assume it's
>15:00 UT.  This will become:
> 
>   Astronomer's JD:  2450268.125
>   NORAD "JD":           185.625
> 
>The NORAD "JD" is simply a count of the number of days into the year, and
>it's reset to 1 at the beginning of each new year.
> 
>I once complained to T.S. Kelso (he's the one who use to post
>satellite orbital elements in sci.space.news) about this usage of
>"JD".  He responded that he understood my point of view, but that
>this usage now is so widespread within NORAD that there's no hope in
>changing it.
> 

I've seen it elsewhere.  The misuse of the term "Julian Day" to 
represent day-of-year has not been at all uncommon in the area of 
tracking satellites and processing the data. 

				Barry Schlesinger



From owner-fitsbits at tarsier.cv.nrao.edu  Sat Jul  6 14:59:41 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA13976; Sat, 6 Jul 1996 14:59:41 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id QAA10413; Fri, 5 Jul 1996 16:29:42 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id QAA16838 for <fitsbits at fits>; Fri, 5 Jul 1996 16:29:37 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA11014; Fri, 5 Jul 96 16:29:35 EDT
To: fitsbits at fits.cv.nrao.edu
Date: Fri, 05 Jul 1996 15:07:48 +0100
From: Peter Bunclark <psb at ast.cam.ac.uk>
Message-Id: <31DD21B4.4D74 at ast.cam.ac.uk>
Organization: Royal Greenwich Observatory
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!lll-winken.llnl.gov!uwm.edu!cs.utexas.edu!swrinde!howland.reston.ans.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!lyra.csx.cam.ac.uk!news
References: <4r19kv$d6f at infa.central.susx.ac.uk> <31D80C21.7662 at ast.cam.ac.uk> <4r98r6$e6r at darkstar.ucsc.edu> <4rfkf8$idg at electra.saaf.se> <5JUL199609253197 at nssdca.gsfc.nasa.gov>
Subject: Re: MJD - not acceptable according to IAU (?)
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Barry M. Schlesinger wrote:
> > 
> I've seen it elsewhere.  The misuse of the term "Julian Day" to
> represent day-of-year has not been at all uncommon in the area of
> tracking satellites and processing the data.

Did these guys write the Ariane-5 navigation software?

No matter how much you wish for it, some old FITS readers cannot be updated -
don't have source, don't have library, can't remember how to use a line editor...
Software which *is* maintainable is not a problem.
	The ISO-DATE idea seems great to me, perhaps UTC-DATE being a bit more
definite.  I still think it's best to drop DATE-OBS;  then old software can't 
possibly misinterpret it, but old software is much more likely to handle its
absence gracefully.
	As for MJD-OBS, it serves a different purpose;  you don't read it yourself, you let
your period-finding software loose on it.  And as has been pointed out,
the definition is watertight,  if you can't understand the 0.5 day thing then 
you're not clever enough to do astrophysics.

I want to do this:
1) leave MJD-OBS alone, but recommend it is UT of start of observation; comments
         to clarify;
2) Remove DATE-OBS from FITS writers, certainly after 2000.
3) Adopt UTC-DATE in ISO format, allowing full time-resolution - ie new software
    has to be prepared to parse any allowable case.  A reader encountering 
    DATE-OBS and UTC-DATE takes the newer one as true, or, does a consistency
    check between the two.
	UTC-DATE will refer to the start of observation unless comments or other
     descriptors indicate otherwise.

Pete.


From owner-fitsbits at tarsier.cv.nrao.edu  Mon Jul  8 09:44:41 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA19285; Mon, 8 Jul 1996 09:44:41 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id LAA19400; Sun, 7 Jul 1996 11:16:12 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id LAA03173 for <fitsbits at fits>; Sun, 7 Jul 1996 11:16:08 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA00265; Sun, 7 Jul 96 11:16:04 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 7 Jul 1996 11:17:40 +0200
From: pausch at electra.saaf.se (Paul Schlyter)
Message-Id: <4rnvbk$253 at electra.saaf.se>
Organization: Svensk Amat|rAstronomisk F|rening
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in1.uu.net!EU.net!Norway.EU.net!nntp.uio.no!news.kth.se!tybalt.admin.kth.se!merope.saaf.se!electra.saaf.se!not-for-mail
References: <Pine.3.89.9607051404.S15993-0100000 at poseidon.ifctr.mi.cnr.it>
Subject: Re: MJD - not acceptable according to IAU (?)
Newsgroups: sci.astro.fits,sci.astro
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <Pine.3.89.9607051404.S15993-0100000 at poseidon.ifctr.mi.cnr.it>,
Lucio Chiappetti  <lucio at ifctr.mi.cnr.it> wrote:
 
> On 4 Jul 1996, Paul Schlyter wrote:
> 
> > There are more serious ambuiguities involved here though.  MJD is
> > often used, by various people, as any day count, starting at any day
> > they feel is suitable.  And even JD is subject to this: the NORAD
> > people, who keep track of all our artificial satellites, have their
> > own definition of JD. 
>   [...]
> > The NORAD "JD" is simply a count of the number of days into the year, and
> > it's reset to 1 at the beginning of each new year.
> 
>   I've often seen on various (non-astronomical) newsgroups people
>   talking of "Julian Day number" as the number of days in the year.
>   Since I think this is inexact and to be DEPRECATED, I usually respond
>   to such pointing telling them that this is NOT JD (the 244.... thing)
>   but should be called something else.
 
This can be expected among non-specialists.  But I was quite
disappointed to find out that this erroneous use of JD was common in
a space agency!!!
 

This discussion has become off-topic for sci.astri.fits though --
followups to sci.astro

-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf.se        psr at home.ausys.se


From owner-fitsbits at tarsier.cv.nrao.edu  Mon Jul  8 09:50:56 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA19302; Mon, 8 Jul 1996 09:50:56 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id EAA18235; Mon, 8 Jul 1996 04:19:12 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id EAA09908 for <fitsbits at fits>; Mon, 8 Jul 1996 04:19:08 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA06134; Mon, 8 Jul 96 04:19:03 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 7 Jul 1996 21:37:50 GMT
From: seaman at noao.edu (Rob Seaman)
Message-Id: <4rpane$p2r at noao.edu>
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!newsgate.duke.edu!news.mathworks.com!newsfeed.internetmci.com!swrinde!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman
References: <199607040834.KAB05942 at ns2.hq.eso.org>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Preben Grosbol writes:

> It is clear that all major organizations will be able to implement
> the change but there are also smaller sites.

and Peter Bunclark writes:

> some old FITS readers cannot be updated - don't have source, don't
> have library, can't remember how to use a line editor..
> Software which *is* maintainable is not a problem.

If, for some reason, FITS readers cannot be updated - isn't it also
likely that the corresponding FITS writers can't be updated either?
On the other hand, astronomers reducing FITS files written elsewhere
already have larger compatibility issues to deal with than DATE-OBS.

If software cares about DATE-OBS (or DATE, or DATE-END, or...) it will
break whether or not anybody can fix it.  If the software doesn't need
to know the date, it's not likely to bother to parse it.

Should a fundamental decision be driven by unmaintainable software?

Our primary concern should be for the integrity of the FITS standard,
and only secondarily for any particular software.

- Deprecating the DATE keywords is a very large change to the standard.

- Expanding the allowed formats to include DD/MM/YYYY or YYYY-MM-DD is
  a small change.

- Clarifying the meaning of DD/MM/YY to refer explicitly to twentieth
  century dates is NO change at all - and is necessary to avert a threat
  to the astronomical data record.

In any event the easiest fix is simply to add the century digits when
writing the same old keywords, and to add an if-else clause keying off
the length (or format) of the value when reading those keywords.

We also continue to discuss apples and oranges.  MJD clearly addresses
a different need than a human readable (and writable) date.  I would
argue that this is also true of full blown ISO date/times.  Removing
the ability to include a human readable date (in a standard keyword) in
FITS headers would be a drastic change to the standard.  Would the "F"
still stand for "Flexible"?  Readable ASCII headers are central to FITS.

A few comments about ISO 8601 and FITS:

- It is a closed standard - nothing has changed since Carl Malamud's
  "Exploring The Internet", you still have to buy a copy of the standard.
  Presumably we could not reprint selections from the ISO standard
  within the FITS standard.

- When we talk about implementing ISO 8601 dates in FITS, we don't
  really mean that.  We mean implementing a subset of the allowed ISO
  formats.  A FITS keyword should not have so many degrees of freedom.
  (FITS users typically don't need to know the week of the year, for
  instance.)

- The code to parse even a limited subset of ISO 8601 is much more
  complicated than parsing a simple date.

- Issues of keyword precedence are impossible to avoid.  FITS usage
  already includes many redundant keywords - do we want to require more?

- Why should the FITS date keyword (whatever it is) be required to
  include a time, anyway?  If the FITS is ingested into an archive,
  are we to assume that there won't be separate date and time fields
  in the relational database?  Will users be required to phrase SQL
  queries using the full ISO syntax for periods of time?  A date is
  a useful piece of information separate from the time.

- Alternately, would FITS allow truncating ISO-OBS (or whatever) after
  the date?  Imagine the logic required to coherently implement a keyword
  that may or may not contain time information...or that may or may not
  include the seconds, minutes, hours, days or months fields.  Even the
  year is optional - "19" is a legal ISO value denoting the 20th century.

- ISO dates/times refer to the local time zone by default - the "Z" (or
  an explicit hour offset) is required to denote UTC.  For instance:

        "The following strings all indicate the same point
         of time:  12:00Z = 13:00+01:00 = 0700-0500"

  From the web summaries it is unclear whether appending the "Z" to
  a simple date string is permitted.  The ISO date "1996-07-07" refers
  explicitly to a local time zone.  I have no idea what ISO 8601 has
  to say about spacecraft time.  (Is UT "local" to a spacecraft?)

- ISO's idea of universal time may well not be an astronomer's.

Bill Pence's observation that a single keyword string can support
multiple formats (distinguished by length or some other property) is
quite provocative.  Perhaps this will prove of use with other FITS
keywords.  A little bit of this goes a long way, of course.

I agree with Bill's suggestion that the new full precision DATE-OBS
format use ISO conventions, e.g., DATE-OBS='2076-07-04'.  (Note that
trouble in the year 10000 will be avoided by simply adding a fifth
digit to the year field.)  DATE-OBS should not include ISO time
information.

The new FITS date format should, however, part ways with ISO and
be explicitly interpreted as a UT date (without a "Z").  This also
strengthens a weakness in the wording of the current standard:
"Specification of the date using Universal Time is recommended."
Change "recommended" to "required" for the new format.

The DD/MM/YY format will continue to indicate twentieth century dates.
Other DATExxxx keywords will be handled similarly.

If the community wants to establish an unsegmented format (e.g., MJD)
or a combined date/time format (e.g., ISO 8601), these should result
from entirely separate discussions.  Perhaps at some later date MJD-OBS
(and the associated TIMESYS, TIMEREF, etc.) will take precedence over
ISO-OBS, which will in turn take precedence over DATE-OBS and UT (not
to mention LST, HA, and all the other time-like keywords we use).  Do
these sound like negotiations we will finish in 3-1/2 years?  And then
implement?  Will the results of such negotiations be any easier to deal
with for those poor astronomers stuck with unmaintainable code?

Let's just fix the clear and present danger before adding new features,
no matter how attractive, to the standard.

Rob

--
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B


From owner-fitsbits at tarsier.cv.nrao.edu  Mon Jul  8 13:24:03 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA19932; Mon, 8 Jul 1996 13:24:03 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id MAA19719; Mon, 8 Jul 1996 12:15:04 -0400
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id MAA13109 for <fitsbits at fits.cv.nrao.edu>; Mon, 8 Jul 1996 12:14:57 -0400 (EDT)
Received: from poseidon.ifctr.mi.cnr.it (poseidon.ifctr.mi.cnr.it [155.253.2.87]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id MAA13213 for <fitsbits at fits.cv.nrao.edu>; Mon, 8 Jul 1996 12:14:42 -0400 (EDT)
Received: by poseidon.ifctr.mi.cnr.it (5.65/1.34)
	id AA24565; Mon, 8 Jul 1996 18:18:09 +0200
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
Date: Mon, 8 Jul 1996 18:18:08 +0200 (MET DST)
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Reply-To: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Subject: Re: DATE-OBS='31/12/99'
To: fitsbits at fits.cv.nrao.edu
In-Reply-To: <4rpane$p2r at noao.edu>
Message-Id: <Pine.3.89.9607081703.O22450-0100000 at poseidon.ifctr.mi.cnr.it>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

On 7 Jul 1996, Rob Seaman wrote:

> If software cares about DATE-OBS (or DATE, or DATE-END, or...) it will
> break whether or not anybody can fix it.  If the software doesn't need
> to know the date, it's not likely to bother to parse it.

  yes

> In any event the easiest fix is simply to add the century digits when
> writing the same old keywords, and to add an if-else clause keying off
> the length (or format) of the value when reading those keywords.

  yes, perhaps

> We also continue to discuss apples and oranges.  MJD clearly addresses
> a different need than a human readable (and writable) date.  I would

  Yes, I like (and use) dates in the readable form
  YYYY-MON-DD HH:MM:SS.FF  with MON=Jan,Feb etc.

  Incidentally when I defined such form I was inspired by some mail
  quoting some of the ISO formats (which I cannot trace now). I recall
  that the only difference was the presence of a blank between date and
  time instead of a letter (I favoured the blank because of human
  readability ...)

> - The code to parse even a limited subset of ISO 8601 is much more
>   complicated than parsing a simple date.

  otherwise said, applying Ockham's razor. one should use a subset composed 
  of a SINGLE case !

> - Why should the FITS date keyword (whatever it is) be required to
>   include a time, anyway?  

  Personally I believe that a date without a time is no use. In fact
  I've never used something like DATE-OBS (which is just a reserved
  keyword, not a mandatory one ...). I think there is no interest in
  knowing that a given measurement was done on a given date, if one
  cannot know the time !  
  Unless one does a measurement which is more than one day long ...

  We'd been recently designing a format for
  the archiving of XMM EPIC calibrations, and we were planning to use
  a DATE-OBS (because it was a "reserved" keyword) together with a  
  TIME-OBS  ... assuming that was the start of a measurement, and
  also a DATE-END and TIME-END ... Most of this was driven by a
  requirement to have an output file in FITS.
  Since I generally use another format as working format, I've used
  (or am planning to use) a different approach there. The idea is that
  keywords are stored in native binary representation (they can be
  written in ASCII when presented to the user or converted to FITS).
  Besides the "standard" types (I2 I4 R4 R8 CHARACTER) there are some
  "composite" types like dates, angular quantities etc. (they use a
  particular native binary representation, e.g. I4 or R8, but are
  DISPLAYED in an human legible form like   YYYY-MON-DD HH:MM:SS.FF  or
  +dd:mm:ss).
  For dates (intended as date-times for which not excessive precision
  is required) the native format is the Unix time (I4 number of sec since
  1970), and this requires just three routines :

      1 - to convert from "Unix time" to a "time array" (yy mm dd hh mm ss)
      2 - to convert from time array to Unix time
      3 - to format Unix time into ASCII human readable form (this calls
          number 1 and does an internal write)

----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR     | Ma te' vugl' da' quost avis a ti' Orsign 
via Bassini 15 - I-20133 Milano  | Buttet rabios intant te se' pisnign      
Internet: LUCIO at IFCTR.MI.CNR.IT  |             (Rabisch, II 46, 119-120)    
----------------------------------------------------------------------------
For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html             
----------------------------------------------------------------------------


From owner-fitsbits at tarsier.cv.nrao.edu  Mon Jul  8 14:35:01 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA20359; Mon, 8 Jul 1996 14:35:01 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id NAA20036; Mon, 8 Jul 1996 13:54:46 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id NAA13830 for <fitsbits at fits>; Mon, 8 Jul 1996 13:54:40 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA24111; Mon, 8 Jul 96 13:54:38 EDT
To: fitsbits at fits.cv.nrao.edu
Date: Mon, 08 Jul 1996 08:46:02 +0100
From: Peter Bunclark <psb at ast.cam.ac.uk>
Message-Id: <31E0BCBA.A53 at ast.cam.ac.uk>
Organization: Royal Greenwich Observatory
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!uwm.edu!lll-winken.llnl.gov!nntp.coast.net!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news
References: <199607040834.KAB05942 at ns2.hq.eso.org> <4rpane$p2r at noao.edu>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Rob Seaman wrote:
> 
> 
> If, for some reason, FITS readers cannot be updated - isn't it also
> likely that the corresponding FITS writers can't be updated either?
Yes, but the point of FITS is that readers and writers don't correspond to 
each other, rather both correspond to the standard.  Sadly, readers get left
behind in the process.

> 
> If software cares about DATE-OBS (or DATE, or DATE-END, or...) it will
> break whether or not anybody can fix it.  If the software doesn't need
> to know the date, it's not likely to bother to parse it.
Part of my argument is, I would rather it failed completely with `KEYWORD
NOT PRESENT' than fail quietly having secretly got the century wrong.  I bet
if you were using this to compute airmasses at time of observation, for example,
you may well not check manually.


> Should a fundamental decision be driven by unmaintainable software?
No, not really.  I just include that problem as a factor in optimising the
solution.

> 
> Our primary concern should be for the integrity of the FITS standard,
> and only secondarily for any particular software.
> 
> - Deprecating the DATE keywords is a very large change to the standard.
> 
> - Expanding the allowed formats to include DD/MM/YYYY or YYYY-MM-DD is
>   a small change.
Still disagree, this time because of current software, much of which will
parse DD/MM/YYYY without calling an error, and thus not alerting its maintainer
to the need for an update.  (Dates will all apparently be in 1919).


> - Clarifying the meaning of DD/MM/YY to refer explicitly to twentieth
>   century dates is NO change at all - and is necessary to avert a threat
>   to the astronomical data record.
> 
All your points about MJD and about ISO full-format dates makes a lot of sense.

> 
> Bill Pence's observation that a single keyword string can support
> multiple formats (distinguished by length or some other property) is
> quite provocative.  Perhaps this will prove of use with other FITS
> keywords.  A little bit of this goes a long way, of course.
But could make reader-writing very complex!

> 
> I agree with Bill's suggestion that the new full precision DATE-OBS
> format use ISO conventions, e.g., DATE-OBS='2076-07-04'.  (Note that
> trouble in the year 10000 will be avoided by simply adding a fifth
> digit to the year field.)  DATE-OBS should not include ISO time
> information.
> 
> The new FITS date format should, however, part ways with ISO and
> be explicitly interpreted as a UT date (without a "Z").  This also
> strengthens a weakness in the wording of the current standard:
> "Specification of the date using Universal Time is recommended."
> Change "recommended" to "required" for the new format.
> 
> The DD/MM/YY format will continue to indicate twentieth century dates.
> Other DATExxxx keywords will be handled similarly.
> 
> 
> Rob
> 
So is there any chance we could agree on the following:
1) Clarify DD/MM/YY to be 20th century
2) allow alternative DATE-OBS= '1996-07-08'

   The User Guide should advise stopping use of DD/MM/YY; and to use the `-' as
   a field-separator, not to use FORMAT(i4,1x,i2,1x,2i2) so that the year 10000
   will work.  We'll ignore it, of course.
   The format DD/MM/YYYY is NOT allowed.

Please note the climb-down!! Personally, I would still choose a new keyword;
telling a reader to search for a different keyword is greatly simpler than writing
a new date-string parsing algorithm.  However, I believe this is so important I'd
really like to kick it into action.   What's the procedure to declare a standard
extension?


From owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  9 09:48:15 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA24414; Tue, 9 Jul 1996 09:48:15 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id DAA23561; Tue, 9 Jul 1996 03:49:18 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id DAA19517 for <fitsbits at fits>; Tue, 9 Jul 1996 03:49:13 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA23011; Tue, 9 Jul 96 03:49:05 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 8 Jul 1996 15:59:38 GMT
From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Message-Id: <4rrb9a$qgm at post.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!inXS.uu.net!news.mathworks.com!newsfeed.internetmci.com!swrinde!elroy.jpl.nasa.gov!ames!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson
References: <199607040834.KAB05942 at ns2.hq.eso.org> <4rpane$p2r at noao.edu>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

seaman at noao.edu (Rob Seaman) writes:

>A few comments about ISO 8601 and FITS:

>- It is a closed standard - nothing has changed since Carl Malamud's
>  "Exploring The Internet", you still have to buy a copy of the standard.
>  Presumably we could not reprint selections from the ISO standard
>  within the FITS standard.

However, you could reprint from the CCSDS standards documentation, which is a
subset of the ISO-8601 standard.

>- When we talk about implementing ISO 8601 dates in FITS, we don't
>  really mean that.  We mean implementing a subset of the allowed ISO
>  formats.  A FITS keyword should not have so many degrees of freedom.
>  (FITS users typically don't need to know the week of the year, for
>  instance.)

Agreed.  Again, look at the CCSDS documentation.

>- The code to parse even a limited subset of ISO 8601 is much more
>  complicated than parsing a simple date.

Depends on how limited.  

>- Issues of keyword precedence are impossible to avoid.  FITS usage
>  already includes many redundant keywords - do we want to require more?

FITS is a creaky, backwater standard full of out-moded concepts.  Do we want to
keep it that way?

>- Why should the FITS date keyword (whatever it is) be required to
>  include a time, anyway?  If the FITS is ingested into an archive,
>  are we to assume that there won't be separate date and time fields
>  in the relational database?  Will users be required to phrase SQL
>  queries using the full ISO syntax for periods of time?  A date is
>  a useful piece of information separate from the time.

I guess it depends on what kind of astronomy you do.  For our observations
(solar) a date without a time is pretty meaningless.  Anyways, as I understand
the ISO/CCSDS standard, one can give a date without a time if desired.

Bill Thompson


From owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  9 09:49:54 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA24426; Tue, 9 Jul 1996 09:49:54 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id EAA23661; Tue, 9 Jul 1996 04:52:07 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id EAA19943 for <fitsbits at fits>; Tue, 9 Jul 1996 04:52:02 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA24651; Tue, 9 Jul 96 04:52:00 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 8 Jul 1996 16:05:25 GMT
From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Message-Id: <4rrbk5$qi2 at post.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!news.iag.net!newsfeeder.sdsu.edu!newspump.sol.net!homer.alpha.net!uwm.edu!math.ohio-state.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson
Subject: CCSDS standard
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk


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 owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul  9 14:39:14 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA00739; Tue, 9 Jul 1996 14:39:14 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id NAA00536; Tue, 9 Jul 1996 13:49:30 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id NAA23543 for <fitsbits at fits>; Tue, 9 Jul 1996 13:49:19 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA11732; Tue, 9 Jul 96 13:49:11 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 8 Jul 1996 20:38:17 GMT
From: sla at umbra.ucolick.org (Steve Allen)
Message-Id: <4rrrjp$s1t at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory, Santa Cruz
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!inXS.uu.net!news.mathworks.com!newsfeed.internetmci.com!miwok!bdt.com!hal.COM!darkstar.UCSC.EDU!umbra.ucolick.org!sla
References: <199607040834.KAB05942 at ns2.hq.eso.org> <4rpane$p2r at noao.edu>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <4rpane$p2r at noao.edu>, Rob Seaman <seaman at noao.edu> wrote:

>Should a fundamental decision be driven by unmaintainable software?
>
>Our primary concern should be for the integrity of the FITS standard,
>and only secondarily for any particular software.
>
>- Deprecating the DATE keywords is a very large change to the standard.
>
>- Expanding the allowed formats to include DD/MM/YYYY or YYYY-MM-DD is
>  a small change.

>In any event the easiest fix is simply to add the century digits when
>writing the same old keywords, and to add an if-else clause keying off
>the length (or format) of the value when reading those keywords.

>Bill Pence's observation that a single keyword string can support
>multiple formats (distinguished by length or some other property) is
>quite provocative.  Perhaps this will prove of use with other FITS
>keywords.  A little bit of this goes a long way, of course.

To someone who feels he has already hand-crafted one too many FITS
reader/writer codes this goes a very long way.  Manually adding extra
IF/ELSE/ENDIF clauses to code is a good way to create more
unmaintainable software.  It is best to avoid such problems
altogether.  Unfortunately the only choice available which solves the
Y2K problem is whether to add the IFs to the sections of the code that
seek the keyword or to the sections of the code that parse the value.

At Lick we are toying with a FITS keyword database.  One of the goals
of this effort is the automated generation of FITS reader and writer
code.  To the extent that we have looked at this in relation to our
database we agree with Rob Seaman.  In the case of the DATE-OBS/Y2K
problem the better solution is to keep the DATE-OBS keyword and change
the syntax of its value.

This situation reminds us that FITS is a human-readable, archival
standard much moreso than it is a machine-readable, data-processing
standard.
--
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 owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 10 00:37:36 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id AAA05254; Wed, 10 Jul 1996 00:37:36 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id UAA03235; Tue, 9 Jul 1996 20:02:14 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id UAA26289 for <fitsbits at fits>; Tue, 9 Jul 1996 20:02:09 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA26361; Tue, 9 Jul 96 20:02:06 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 9 Jul 1996 06:31:46 GMT
From: sla at umbra.ucolick.org (Steve Allen)
Message-Id: <4rsuci$aj1 at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory, Santa Cruz
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!olivea!hal.COM!darkstar.UCSC.EDU!umbra.ucolick.org!sla
References: <4rrbk5$qi2 at post.gsfc.nasa.gov>
Subject: Re: CCSDS standard
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <4rrbk5$qi2 at post.gsfc.nasa.gov>,
William Thompson <thompson at orpheus.nascom.nasa.gov> wrote:

>                  CCSDS RECOMMENDATION FOR TIME CODE FORMATS

>The format for ASCII Time Code A is as follows:
>
>        YYYY-MM-DDThh:mm:ss.d->dZ

>        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 owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 10 00:38:01 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id AAA05267; Wed, 10 Jul 1996 00:38:01 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id VAA04346; Tue, 9 Jul 1996 21:55:32 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA27084 for <fitsbits at fits>; Tue, 9 Jul 1996 21:55:28 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA00670; Tue, 9 Jul 96 21:55:25 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 9 Jul 1996 17:17:54 GMT
From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Message-Id: <4ru482$j4t at post.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!nntp.coast.net!news-res.gsl.net!news.gsl.net!swrinde!elroy.jpl.nasa.gov!ames!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson
References: <4rrbk5$qi2 at post.gsfc.nasa.gov> <4rsuci$aj1 at darkstar.UCSC.EDU>
Subject: Re: CCSDS standard
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

sla at umbra.ucolick.org (Steve Allen) writes:

>In article <4rrbk5$qi2 at post.gsfc.nasa.gov>,
>William Thompson <thompson at orpheus.nascom.nasa.gov> wrote:

>>                  CCSDS RECOMMENDATION FOR TIME CODE FORMATS

>>The format for ASCII Time Code A is as follows:
>>
>>        YYYY-MM-DDThh:mm:ss.d->dZ

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

>Looks remarkably similar to ISO.

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

Bill Thompson


From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 10 10:37:24 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA08727; Wed, 10 Jul 1996 10:37:24 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id DAA06548; Wed, 10 Jul 1996 03:01:37 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id DAA29270 for <fitsbits at fits>; Wed, 10 Jul 1996 03:01:33 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA10577; Wed, 10 Jul 96 03:01:30 EDT
To: fitsbits at fits.cv.nrao.edu
Date: Tue, 09 Jul 1996 13:19:24 +0100
From: Peter Bunclark <psb at ast.cam.ac.uk>
Message-Id: <31E24E4C.22F2 at ast.cam.ac.uk>
Organization: Royal Greenwich Observatory
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in1.uu.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!lyra.csx.cam.ac.uk!news
References: <Pine.3.89.9607081703.O22450-0100000 at poseidon.ifctr.mi.cnr.it>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Lucio Chiappetti wrote:
> 
>   Personally I believe that a date without a time is no use. In fact
>   I've never used something like DATE-OBS (which is just a reserved
>   keyword, not a mandatory one ...). I think there is no interest in
>   knowing that a given measurement was done on a given date, if one
>   cannot know the time !
Yes, of course, and all observatories recored the time, but in a different keyword.
The date and time must be collected atomically, otherwise it gets confusing
around midnight, but because PAPER I suggests DATE-0BS we've all been using that,
and storing time in a different keyword.  You might argue it makes  the parser
a bit easier.


>   We'd been recently designing a format for
>   the archiving of XMM EPIC calibrations, and we were planning to use
>   a DATE-OBS (because it was a "reserved" keyword) together with a
>   TIME-OBS  ... assuming that was the start of a measurement, and
>   also a DATE-END and TIME-END ... Most of this was driven by a
>   requirement to have an output file in FITS.
>   Since I generally use another format as working format, I've used
>   (or am planning to use) a different approach there. The idea is that
>   keywords are stored in native binary representation (they can be

Very good.  But nothing at all to do with FITS.  Most packages convert original
FITS data into a more computationally efficient form.


Pete.


From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 10 15:29:34 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA10473; Wed, 10 Jul 1996 15:29:34 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA10172; Wed, 10 Jul 1996 14:21:19 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA03919 for <fitsbits at fits>; Wed, 10 Jul 1996 14:21:11 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA02814; Wed, 10 Jul 96 14:21:07 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 9 Jul 1996 21:40:59 GMT
From: davis at space.mit.edu (John E. Davis)
Message-Id: <slrn4u5kfa.nm1.davis at aluche.mit.edu>
Organization: Center for Space Research
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!spool.mu.edu!usenet.eel.ufl.edu!news.ultranet.com!homer.alpha.net!uwm.edu!news.moneng.mei.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!davis
References: <199607022242.SAA01439 at tetra.gsfc.nasa.gov>
Reply-To: davis at space.mit.edu
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

On 3 Jul 1996 09:58:08 -0400, William Pence <pence at tetra.gsfc.nasa.gov>
wrote:
 : in addition to the current dd/mm/yy format.  Thus all the following
 : examples would be legal:
 : 
 :      DATE-OBS= '24/06/98' 
 :      DATE-OBS= '2010-02-13T13:53:10.3Z' 
 :      DATE-OBS= '2010-02-13'

If the statement,

   ``Reading the data values from a FITS file should not require
   decoding any more than the first eight characters of a character
   string value of a keyword.''

from NOST 100-1.0, section 5.3.2.1 on character string formats applies
then there could be trouble.  Perhaps this statement should be changed
to something more reasonable to specify that ALL characters with the
exception of trailing whitespace of a character string are meaningful.

-- 
John E. Davis                   Center for Space Research/AXAF Science Center
617-258-8119                    MIT 37-662c, Cambridge, MA 02139
http://space.mit.edu/~davis



From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 10 15:30:13 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA10488; Wed, 10 Jul 1996 15:30:13 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id PAA10347; Wed, 10 Jul 1996 15:02:49 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id PAA04259 for <fitsbits at fits>; Wed, 10 Jul 1996 15:02:44 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA04594; Wed, 10 Jul 96 15:02:41 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 9 Jul 1996 21:49:35 GMT
From: davis at space.mit.edu (John E. Davis)
Message-Id: <slrn4u5kvf.nm1.davis at aluche.mit.edu>
Organization: Center for Space Research
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!spool.mu.edu!munnari.OZ.AU!news.mel.connect.com.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!tank.news.pipex.net!pipex!news.mathworks.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!davis
References: <199607040834.KAB05942 at ns2.hq.eso.org> <4rpane$p2r at noao.edu> <4rrrjp$s1t at darkstar.UCSC.EDU>
Reply-To: davis at space.mit.edu
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

On 8 Jul 1996 20:38:17 GMT, Steve Allen <sla at umbra.ucolick.org>
wrote:
 : This situation reminds us that FITS is a human-readable, archival
 : standard much moreso than it is a machine-readable, data-processing
 : standard.

Precisely.  With data sets growing in size every year, one has to
wonder whether or not it is preferable to choose a file format that
lends itself to less ambiguous data-processing.
-- 
John E. Davis                   Center for Space Research/AXAF Science Center
617-258-8119                    MIT 37-662c, Cambridge, MA 02139
http://space.mit.edu/~davis



From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 10 18:22:49 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id SAA11860; Wed, 10 Jul 1996 18:22:49 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id RAA11408; Wed, 10 Jul 1996 17:49:18 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id RAA05561 for <fitsbits at fits>; Wed, 10 Jul 1996 17:49:06 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA11045; Wed, 10 Jul 96 17:49:01 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 10 Jul 1996 00:31:11 GMT
From: seaman at noao.edu (Rob Seaman)
Message-Id: <4rutkf$gde at noao.edu>
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!sgigate.sgi.com!newsfeeder.sdsu.edu!newspump.sol.net!homer.alpha.net!uwm.edu!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman
References: <199607022242.SAA01439 at tetra.gsfc.nasa.gov> <slrn4u5kfa.nm1.davis at aluche.mit.edu>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

John E. Davis writes:

> If the statement,
> 
>    ``Reading the data values from a FITS file should not require
>    decoding any more than the first eight characters of a character
>    string value of a keyword.''
> 
> from NOST 100-1.0, section 5.3.2.1 on character string formats applies
> then there could be trouble.  Perhaps this statement should be changed
> to something more reasonable to specify that ALL characters with the
> exception of trailing whitespace of a character string are meaningful.

This "fixed format" is only required for the mandatory FITS keywords,
for instance, XTENSION names.  Many other keywords already rely on long
values, of course.  Clarifying the documentation can't hurt, though.

Rob
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B


From owner-fitsbits at tarsier.cv.nrao.edu  Thu Jul 11 00:50:01 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id AAA14427; Thu, 11 Jul 1996 00:50:01 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id VAA13373; Wed, 10 Jul 1996 21:50:31 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA07199 for <fitsbits at fits>; Wed, 10 Jul 1996 21:50:25 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA19640; Wed, 10 Jul 96 21:50:22 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 10 Jul 1996 09:40:07 GMT
From: seaman at noao.edu (Rob Seaman)
Message-Id: <4rvtpn$qc3 at noao.edu>
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!venus.sun.com!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman
References: <Pine.3.89.9607081703.O22450-0100000 at poseidon.ifctr.mi.cnr.it> <31E24E4C.22F2 at ast.cam.ac.uk>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Lucio Chiappetti writes:

> Personally I believe that a date without a time is no use. In fact
> I've never used something like DATE-OBS (which is just a reserved
> keyword, not a mandatory one ...). I think there is no interest in
> knowing that a given measurement was done on a given date, if one
> cannot know the time !

There have been several other comments similar to this.

Clearly, a time resolution of a day is rarely scientifically useful.
The justification for including MJD (or JD) in FITS headers is just as
clear, although the associated complexities such as supporting multiple
systems of time may themselves be only rarely necessary.

But FITS headers are not only scientific documents, they are political
documents, and also often serve as the primary log sheet for an
astronomer's observing run.  The date is usually the easiest way to
select one proprietary set of data from another - at least I find this
true of data from general-purpose, public, ground-based, optical-IR
observatories.

More to the point, a date and a time don't just represent different
sampling intervals from an inertial continuum of time - our telescopes
are anchored to a moving Earth.  This is true even for the space-based
telescopes - at least the ones in Earth orbit.  All our data contain
diurnal (and annual) signatures of one kind or another.  Keeping the
date separate is the same thing as keeping the time separate as a
searchable keyword.

A not insignificant bookkeeping issue for both MJD and ISO 8601 is the
simple length of the keyword value.  Measuring the time of an observation
to millisecond accuracy requires 13 significant figures for MJD and 17
significant "figures" (ignoring punctuation) for a fully qualified ISO
string.  Not only may a particular series of observations not require
that much absolute precision, they may also be better served by times
recorded as relative offsets.

No single date/time mechanism suffices for all astronomical data.
FITS should remain flexible on this issue.

Rob
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B


From owner-fitsbits at tarsier.cv.nrao.edu  Thu Jul 11 00:51:01 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id AAA14439; Thu, 11 Jul 1996 00:51:01 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id AAA14316; Thu, 11 Jul 1996 00:23:43 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id AAA08250 for <fitsbits at fits>; Thu, 11 Jul 1996 00:23:39 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA25062; Thu, 11 Jul 96 00:23:36 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 10 Jul 1996 17:53:09 GMT
From: seaman at noao.edu (Rob Seaman)
Message-Id: <4s0qm5$acp at noao.edu>
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!newsxfer2.itd.umich.edu!tank.news.pipex.net!pipex!oleane!jussieu.fr!math.ohio-state.edu!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman
References: <199607022242.SAA01439 at tetra.gsfc.nasa.gov> <10JUL199613231384 at nssdca.gsfc.nasa.gov>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Barry M. Schlesinger writes:

> The eight character rule stemmed from some limitations of hardware 
> and/or software.  Every once in a while I still see notes about some 
> package that has a problem with longer strings.

Eight ASCII characters also form a 64 bit "magic" number.  This can
be used to discriminate extension types, for example, by using similar
techniques to the unix "file" command (note that /etc/magic also allows
for an byte offset).  The value isn't double word aligned, unfortunately,
since it has to start in column 12.

Rob
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B


From owner-fitsbits at tarsier.cv.nrao.edu  Thu Jul 11 09:44:30 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA17573; Thu, 11 Jul 1996 09:44:30 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id EAA16661; Thu, 11 Jul 1996 04:53:28 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id EAA10051 for <fitsbits at fits>; Thu, 11 Jul 1996 04:53:24 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA02538; Thu, 11 Jul 96 04:53:20 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 10 Jul 1996 13:23 EDT
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger)
Message-Id: <10JUL199613231384 at nssdca.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!venus.sun.com!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger
References: <199607022242.SAA01439 at tetra.gsfc.nasa.gov> <slrn4u5kfa.nm1.davis at aluche.mit.edu>
Subject: Re: DATE-OBS='31/12/99'
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <slrn4u5kfa.nm1.davis at aluche.mit.edu>, davis at space.mit.edu writes...
>On 3 Jul 1996 09:58:08 -0400, William Pence <pence at tetra.gsfc.nasa.gov>
>wrote:
> : ... the following examples would be legal:
> : 
> :      DATE-OBS= '24/06/98' 
> :      DATE-OBS= '2010-02-13T13:53:10.3Z' 
> :      DATE-OBS= '2010-02-13'
> 
>If the statement,
> 
>   ``Reading the data values from a FITS file should not require
>   decoding any more than the first eight characters of a character
>   string value of a keyword.''
> 
>from NOST 100-1.0, section 5.3.2.1 on character string formats applies
>then there could be trouble.  Perhaps this statement should be changed
>to ... specify that ALL characters with the
>exception of trailing whitespace of a character string are meaningful.

This statement addresses values of keywords that are needed by the 
software to actually read the data of HDU in the FITS file, that is,
the actual process of parsing the data, as opposed to keywords that
are used to provide the scientific context.  The User's Guide
expresses the idea in the following way, 

`` If the reading program requires the value of the keyword to 
interpret the data properly, the information should be in the first 
eight characters.... For purely descriptive material it is not so 
critical to have the meaning clear from the first eight characters....''

As the DATE-OBS keyword is used for understanding the content, not for 
instructing the program on how to read the data, the eight-character 
rule does not apply.

The eight character rule stemmed from some limitations of hardware 
and/or software.  Every once in a while I still see notes about some 
package that has a problem with longer strings.

				Barry Schlesinger
				FITS Support Office
				GSFC/ADF  


From owner-fitsbits at tarsier.cv.nrao.edu  Mon Jul 22 15:46:35 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id PAA32689; Mon, 22 Jul 1996 15:46:35 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA32572; Mon, 22 Jul 1996 14:58:13 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA05093 for <fitsbits at fits>; Mon, 22 Jul 1996 14:58:08 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA11021; Mon, 22 Jul 96 14:58:05 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 21 Jul 1996 22:04:23 GMT
From: gfl at mail.ast.cam.ac.uk (Geraint Lewis)
Message-Id: <4su9h7$qdm at lyra.csx.cam.ac.uk>
Organization: Institute of Astronomy, Cambridge
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!gatech!ncar!csn!nntp-xfer-1.csn.net!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexas.edu!swrinde!tank.news.pipex.net!pipex!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!lyra.csx.cam.ac.uk!mail.ast.cam.ac.uk!gfl
Subject: Copying fits tapes
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk


 Hi - I am having serious problems copying a fits tape
 over a network. I have an dat tape, written at ESO, 
 which I need to copy over to an exabyte. The dat drive
 is on a sun (SunOS4.1.3) and the exabyte is on an Alpha
 (OSF/1). lack of disk space does not allow me to copy the
 files off, using iraf, and then back on, so I thought I 
 would use dd - 

 From the sun, I typed:


 dd if=/dev/rst0 bs=2880 files=1000 | ( rsh alpha of=/dev/rmt/0h  ---
 bs=2880 files=1000 )

 The copy appears to work, (ie - blocks in and out agree), but when
 I try and read the exabyte, using iraf under OSF and VMS, as well
 as IDL(vms) the first file is read successfully (ie can be displayed
 etc), but then nothing happens, no prompt is returned, no second file
 is read, everything just sits there. I have tried several dd's now, but 
 this seems to be the outcome.

 Would somebody care to comment on where the possible problem is ?

 Thanks - Geraint

 ps - please feel free to mail me questions on the above, I will put
 together a solution and post it when I have one....


From owner-fitsbits at tarsier.cv.nrao.edu  Tue Jul 23 14:05:48 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA03810; Tue, 23 Jul 1996 14:05:48 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id MAA03533; Tue, 23 Jul 1996 12:42:05 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id MAA13991 for <fitsbits at fits>; Tue, 23 Jul 1996 12:41:55 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA27000; Tue, 23 Jul 96 12:41:51 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 22 Jul 1996 21:37:04 GMT
From: gfl at mail.ast.cam.ac.uk (Geraint Lewis)
Message-Id: <4t0sa0$n0i at lyra.csx.cam.ac.uk>
Organization: Institute of Astronomy, Cambridge
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!inXS.uu.net!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!mail.ast.cam.ac.uk!gfl
References: <4su9h7$qdm at lyra.csx.cam.ac.uk>
Subject: Re: Copying fits tapes
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

In article <4su9h7$qdm at lyra.csx.cam.ac.uk>, gfl at mail.ast.cam.ac.uk (Geraint Lewis) writes:
|> 
     Original message deleted:
|>

 I received a number of responses on my tape copying problem - 
 The problem was to do with EOFs being sent down a pipe, so 
 if files are copied one at a time, they are written, and then
 can be re-read, properly:-

 eg:

 $ set n = 1
 $ while ( $n <= 1000 )
 $   dd if=/dev/nrst0 ibs=2880 | rsh alpha dd of=/dev/nrmt0h obs=2880
 $    at  n++
 $ end

 works a treat: Note that the n in the tape drive name is needed to 
 ensure that it does not rewind between read/writes.

 Many thanks to "Peter G. Ford" <pgf at space.mit.edu> who supplied the above
                 Peter Bunclark <psb at ast.cam.ac.uk>
                 Preben Grosbol <pgrosbol at eso.org>
                 Jim Lewis      <jrl at ast.cam.ac.uk>

 for your help


From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 24 14:36:08 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA10440; Wed, 24 Jul 1996 14:36:08 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id OAA10399; Wed, 24 Jul 1996 14:28:45 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA24897 for <fitsbits at fits>; Wed, 24 Jul 1996 14:28:38 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA20335; Wed, 24 Jul 96 14:28:34 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 23 Jul 1996 16:58 EDT
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger)
Message-Id: <23JUL199616585769 at nssdca.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!venus.sun.com!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger
Reply-To: fits at nssdca.gsfc.nasa.gov
Subject: Sources of FITS Information
Newsgroups: sci.astro.fits,sci.data.formats,sci.answers,news.answers
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Archive-name: astronomy/fits/info-sources
Last-modified: 1996/07/23

--------
		Sources of FITS Information 

Preface 	

This material on sources of Flexible Image Transport System (FITS)
information is posted and updated periodically by the FITS Support
Office at the NASA Goddard Space Flight Center (GSFC).  It discusses
where general FITS information, including some answers to frequently
asked questions, can be found, and provides sources for detailed
information on FITS software and documentation. 

-------

FITS Support Office

The FITS Support Office maintains a library of FITS information
accessible from http://ssdoo.gsfc.nasa.gov/astro/fits/fits_home.html or
ftp://nssdc.gsfc.nasa.gov/pub/fits/.  The material available includes

o	"Definition of FITS," a codification of FITS for the 
	NASA/Science Office of Standards and Technology (NOST),
	available in LaTeX, uncompressed PostScript, compressed 
	PostScript and (usually) ASCII text
	(The ASCII text version may not be available for a short 
	while after the announcement of a new version.)

o	"A User's Guide to FITS", published by the FITS Support Office, 
	in LaTeX, and compressed and uncompressed PostScript 

o	Revisions to version 1.0 of the "Definition of FITS" covering the
	specification of units that were incorporated 
	into version 1.1 (text)

o	A current list of the extension type (structure) names
	registered with the International Astronomical Union FITS
	Working Group (IAUFWG) (text)

o	Rules for physical blocking on various media adopted by
	the IAUFWG (text)  

In the same directory but accessible directly via 
http://ssdoo.gsfc.nasa.gov/astro/fits/basics_info.html is the FITS
Basics and Information that used to be regularly posted to
sci.astro.fits and sci.data.formats.  It continues to be revised to
reflect current FITS developments.  It contains the following material: 

o	An overview of FITS

o	A list of FITS documents  

o	A list of software packages that support FITS, 
		including FITS-image converters for various platforms

o	A list of on-line FITS resources

o	A description of the FITS Support Office 

The hypertext version provides links to many of the documents, 
software, and network locations listed.  The text version provides 
information on how to obtain much of this material.

There is also a hypertext version of the List of Registered  Extensions. 

Links from the Web page and subdirectories of the ftp directory contain
	
o	Software developed by the FITS Support Office.  

o	Error test files: primary HDUs useful for testing the ability
	of software designed to read FITS files to cope with files that 
	have errors or are non-standard.  These files should be 
	downloaded in binary form.

Printed copies of the material in the FITS directory can be obtained
from the Coordinated Request and User Support Office (CRUSO):  

(Postal) Coordinated Request and User Support Office
         Code 633
	 National Space Science Data Center
	 NASA Goddard Space Flight Center
	 Greenbelt MD 20771 USA

(Electronic mail) request at nssdca.gsfc.nasa.gov

(Telephone)  +1-301-286-6695 8:00 A. M. - 4:30 P.M. U. S. Eastern Time
(-0500 from the last Sunday in October through the first Saturday in
April; -0400 the remainder of the year) 
	When no one is available, messages can be left on voice mail. 
(FAX) +1-301-286-1635

-------

National Radio Astronomy Observatory (NRAO)

A FITS Archive can be found at URL http://fits.cv.nrao.edu/ or 
at ftp://fits.cv.nrao.edu/fits, located at NRAO.  This machine supports a
WAIS server named nrao-fits which has an index of all of the
FITS-related text files in the archive; the file nrao-fits.src is
available at think.com and at
ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src.  

Some of the more noteworthy materials in this archive are 

o	Drafts of proposed additions to the FITS standard and other 
	drafts that may in the future be formally proposed

o	Text of any detailed proposals currently being discussed by 
	the FITS committees

o	A collection of documents on World Coordinate Systems, 
	including the current draft proposal

o	Conventions specific to particular projects or disciplines

o 	Software for various environments and Usenet postings about
	code 

o	Sample data and special test files designed to measure the
        ability of a FITS reader to handle a wide variety of FITS files

o	Archives of traffic on FITS-related newsgroups and exploders

A separate NRAO site, http://www.cv.nrao.edu/~bcotton/fitsview.html,
provides information on the FITSview family of software packages for
display of FITS images on Microsoft Windows 3.1 and Windows 95, Apple
Macintosh, and Unix/X-Windows, with links to the software. It also
links to a number of sources of astronomical FITS images. 

-------

HEASARC

The NASA/Goddard High Energy Astrophysics Science Archive Research
Center (HEASARC) Web server at 
http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html and the anonymous
ftp access through ftp://heasarc.gsfc.nasa.gov/fits_info/ provide FITS
material.  HEASARC has developed the FITSIO package of software routines
for easily reading and writing FITS files, with a FORTRAN and a beta
(but well-tested) C version available, portable to a wide variety of
machines.  There is also the FTOOLS collection of software tools and the
VERIFITS FITS conformance verifier. HEASARC software is available
directly through
http://heasarc.gsfc.nasa.gov/docs/heasarc/tech_res_software.html or
ftp://heasarc.gsfc.nasa.gov/fits_info/software/ . 

The HEASARC server also provides information from the HEASARC FITS
Working Group, (HFWG) the internal legislative body on FITS-related
matters within the Office of Guest Investigator Programs (OGIP) at
NASA/GSFC, at 
http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html or
ftp://heasarc.gsfc.nasa.gov/fits_info/ . The HFWG has developed a number
of FITS conventions that are more specific than the requirements of the
FITS standards. Proposed conventions are publicized to the FITS
community as a whole, with the goal of collaborative development of a
set of conventions that will be accepted throughout the community as
well as within OGIP/HEASARC. 

-------

Direct questions about this posting to 
				Barry M. Schlesinger
				Coordinator,
				FITS Support Office

Electronic mail: fits at nssdca.gsfc.nasa.gov
Telephone:       +1-301-441-4205		

The FITS Support Office is operated under the guidance of the
NASA/GSFC Astrophysics Data Facility.


From owner-fitsbits at tarsier.cv.nrao.edu  Fri Jul 26 09:34:37 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA27084; Fri, 26 Jul 1996 09:34:37 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id HAA26186; Fri, 26 Jul 1996 07:36:21 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id HAA02203 for <fitsbits at fits>; Fri, 26 Jul 1996 07:36:17 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA21334; Fri, 26 Jul 96 07:36:13 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 25 Jul 1996 16:28 EDT
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger)
Message-Id: <25JUL199616280770 at nssdca.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!news.sgi.com!news.msfc.nasa.gov!pendragon!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger
Subject: Request for conventions - for FITS User's Guide
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk


At the FITS Support Office, we are currently generating a new version 
of the User's Guide.  The section on Advanced FITS will contain 
discussions of a number of proposals and conventions that have been
publicly discussed but are not part of the new rules, in particular 

o	The three conventions in the appendixes to the binary tables 
		paper

o	The Green Bank array-in-table convention

o	The Grouping proposal

o	The Checksum proposal

o	A number of HEASARC conventions
	- Syntax for keyword and column names
	- CREATOR keyword
	- TSORTKEY keyword
 	- Keywords for maximum and minimum values in table columns

If there are other conventions that are in wide use and acceptable to 
the community at large, we would like to include them as well.  If 
there is an additional convention that you think should be included,
post a description or pointer to a description to 
sci.astro.fits=fitsbits before August 12. 



					Barry M. Schlesinger
					FITS Support Office
					GSFC/ADF



From owner-fitsbits at tarsier.cv.nrao.edu  Fri Jul 26 09:48:28 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id JAA27208; Fri, 26 Jul 1996 09:48:28 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id JAA27182; Fri, 26 Jul 1996 09:47:19 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id JAA02391 for <fitsbits at fits>; Fri, 26 Jul 1996 09:47:15 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA24604; Fri, 26 Jul 96 09:47:13 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 26 Jul 1996 13:47:06 GMT
From: dwells at nrao.edu (Don Wells)
Message-Id: <DWELLS.96Jul26094706 at fits.cv.nrao.edu>
Organization: nrao
Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells
Subject: On the Year 2000 issue
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk


Dear Friends of FITS,

Peter Bunclark of RGO raised the "DATE-OBS='31/12/99'" issue in a
posting to sci.astro.fits/fitsbits on 1996-06-24.  This question was
discussed extensively in sci.astro.fits over the succeeding three
weeks.  It appears that all major arguments have been put forward.

This issue is important. We need to have a solution in operation by
1999, and we would all feel better if it were settled even sooner.

Two solutions were proposed in sci.astro.fits. We could implement either 
   1) a new data value string definition for the 'DATExxxx' keywords, or
   2) a new set of keywords to replace the 'DATExxxx' ones.
Both of these options would have both good and bad consequences. 

We (the worldwide FITS community) need to choose either (1) or (2).
Preben Grosbol (former Chair of the IAU FITS Working Group, Chair of
the European FITS Committee) suggested to me and Ernst Raimond
(vice-Chair of IAU-FWG) in private Email a procedure to identify the
better of the two options:

  1) Chairmen (and other experts) will be asked for their opinion
     concerning the 'legal' state and impact of changing the 
     definition of the 'date value string'.

  2) The IAU FITS Working Group (which includes chairmen of local FITS
     Groups) will be asked two questions: a) which proposal they prefer,
     and b) if they would vote against either of the two proposals.

  3) A general e-mail poll with the same questions will be conducted
     through sci.astro.fits/fitsbits.

  4) Based on the results, one proposal will be selected for consideration 
     by the three local FITS Committees.

Ernst and I consider this proposed procedure to be a good approach.  I
expect that we could complete this procedure by the time of the
ADASS'96 meeting in Charlottesville on September 22 (we are well aware
that many people will be on vacation in August).

If any of you want to suggest modifications to the proposed procedure,
or to raise objections to it, please send me private Email by next
Thursday August 1. I intend to ask Preben to carry out the procedure.

For the record, I would be able to vote for either (1) or (2) if the
details of the two proposals are suitably arranged.

Regards,
Don Wells (Chair of IAU FITS Working Group)
--
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
                    http://fits.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA


From owner-fitsbits at tarsier.cv.nrao.edu  Sat Jul 27 01:45:40 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id BAA02542; Sat, 27 Jul 1996 01:45:40 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id SAA00763; Fri, 26 Jul 1996 18:58:08 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id SAA03304 for <fitsbits at fits>; Fri, 26 Jul 1996 18:58:03 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA15654; Fri, 26 Jul 96 18:57:59 EDT
To: fitsbits at fits.cv.nrao.edu
Date: Fri, 26 Jul 1996 08:41:56 -0500
From: Xinjian Lu <xlu at ncsa.uiuc.edu>
Message-Id: <31F8CB24.2443 at ncsa.uiuc.edu>
Organization: University of Illinois at Urbana
Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!news.sgi.com!swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet
Subject: Java-based HDF Browser
Newsgroups: sci.data.formats,sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

Our Java-based HDF browser web page has been set up initially. If you
are
 interested please preview this page. Any  comments are welcome.

      http://hdf.ncsa.uiuc.edu/hdf/java/docs/index.html
 

-Xinjian


From owner-fitsbits at tarsier.cv.nrao.edu  Wed Jul 31 13:38:10 1996
Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id NAA19671; Wed, 31 Jul 1996 13:38:10 -0400
Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) with ESMTP id NAA19643; Wed, 31 Jul 1996 13:36:51 -0400
Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id NAA04549 for <fitsbits at fits>; Wed, 31 Jul 1996 13:36:46 -0400 (EDT)
Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10)
	id AA24241; Wed, 31 Jul 96 13:36:42 EDT
To: fitsbits at fits.cv.nrao.edu
Date: 31 Jul 1996 17:36:27 GMT
From: dwells at nrao.edu (Don Wells)
Message-Id: <DWELLS.96Jul31133627 at fits.cv.nrao.edu>
Organization: nrao
Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells
Subject: On the Year 2000 issue
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at tarsier.cv.nrao.edu
Precedence: bulk

[NOTE: this is a re-posting of a message originally posted by me five
days ago; I have been warned in private Email that there may have been
distribution problems which prevented this message from reaching all
readers of sci.astro.fits/fitsbits. -Don]

Dear Friends of FITS,

Peter Bunclark of RGO raised the "DATE-OBS='31/12/99'" issue in a
posting to sci.astro.fits/fitsbits on 1996-06-24.  This question was
discussed extensively in sci.astro.fits over the succeeding three
weeks.  It appears that all major arguments have been put forward.

This issue is important. We need to have a solution in operation by
1999, and we would all feel better if it were settled even sooner.

Two solutions were proposed in sci.astro.fits. We could implement either 
   1) a new data value string definition for the 'DATExxxx' keywords, or
   2) a new set of keywords to replace the 'DATExxxx' ones.
Both of these options would have both good and bad consequences. 

We (the worldwide FITS community) need to choose either (1) or (2).
Preben Grosbol (former Chair of the IAU FITS Working Group, Chair of
the European FITS Committee) suggested to me and Ernst Raimond
(vice-Chair of IAU-FWG) in private Email a procedure to identify the
better of the two options:

  1) Chairmen (and other experts) will be asked for their opinion
     concerning the 'legal' state and impact of changing the 
     definition of the 'date value string'.

  2) The IAU FITS Working Group (which includes chairmen of local FITS
     Groups) will be asked two questions: a) which proposal they prefer,
     and b) if they would vote against either of the two proposals.

  3) A general e-mail poll with the same questions will be conducted
     through sci.astro.fits/fitsbits.

  4) Based on the results, one proposal will be selected for consideration 
     by the three local FITS Committees.

Ernst and I consider this proposed procedure to be a good approach.  I
expect that we could complete this procedure by the time of the
ADASS'96 meeting in Charlottesville on September 22 (we are well aware
that many people will be on vacation in August).

If any of you want to suggest modifications to the proposed procedure,
or to raise objections to it, please send me private Email by next
Thursday August 1. I intend to ask Preben to carry out the procedure.

For the record, I would be able to vote for either (1) or (2) if the
details of the two proposals are suitably arranged.

Regards,
Don Wells (Chair of IAU FITS Working Group)
--
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
                    http://fits.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA