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 ; 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 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 ; 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 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 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 ; 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 ; 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 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 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 ; 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 ; 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 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 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 ; 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: 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 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 ; 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 ; 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 ; 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 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 ; 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 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 ; 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 ; 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 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 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 ; 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 wrote: > In article <31D80C21.7662 at ast.cam.ac.uk>, Guy Rixon 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 ; 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 wrote: > Steve Allen wrote: > >> In article <31D80C21.7662 at ast.cam.ac.uk>, Guy Rixon 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 ; 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 ; 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 Reply-To: Lucio Chiappetti 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: 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 ; 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 ; 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 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 ; 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: 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 , Lucio Chiappetti 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 ; 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 ; 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 ; 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 Reply-To: Lucio Chiappetti Subject: Re: DATE-OBS='31/12/99' To: fitsbits at fits.cv.nrao.edu In-Reply-To: <4rpane$p2r at noao.edu> Message-Id: 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 ; 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 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 ; 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 ; 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 ; 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 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 ; 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 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 ; 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 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 ; 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 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: 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 ; 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: 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 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 ; 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: 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 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 ; 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> 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 ; 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: <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 ; 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 ; 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> Subject: Re: DATE-OBS='31/12/99' Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article , davis at space.mit.edu writes... >On 3 Jul 1996 09:58:08 -0400, William Pence >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 ; 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 ; 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" who supplied the above Peter Bunclark Preben Grosbol Jim Lewis 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 ; 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 ; 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 ; 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: 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 ; 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 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 ; 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: 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