Subject: A warning for FITS y2k implementors

From: Don Wells <dwells at nrao.edu>
Date: Mon, 9 Feb 1998 13:23:33 -0500 (EST)

An implementor of FITS y2k code told me:

  "..there was one sort of amusing problem with the initial
  implementation that other systems might run into. By default with the
  new-style we include the time. But because of floating point rounding,
  the new style date would turn into previous_day:T23:59:59.99 or
  whatever. While this is fine for systems that read the time part of
  the new format, it would presumably cause systems that ignore the time
  part to think the date was a day earlier than it actually was.."

-Don [Chair, 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: Peter Bunclark <psb at ast.cam.ac.uk>
Date: Tue, 10 Feb 1998 15:40:03 +0000

Looks suspiciously like truncation rather than rounding, hence
is a bug not a feature...  and of course, if you choose to
read the date but not the time you must surely expect up to 24-hour
quantisation errors?  It's a bit like reading a floating-point value
up to the decimal point and ignoring the rest!

Peter.

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 10 Feb 1998 18:48:43 GMT

>  part to think the date was a day earlier than it actually was.."

Something else that implementers of the new standard should be aware of is that
under certain circumstances, a time such as 

	1997-06-30T23:59:60.999

could also be a valid time string, on dates containing leap seconds.

William Thompson

---

From: seaman at noao.edu (Rob Seaman)
Date: 10 Feb 1998 21:33:27 GMT

> up to the decimal point and ignoring the rest!

Bundling the date and time into the same keyword is also no different in
this regard than having separate DATE-OBS and UT (for instance) keywords.
Code that previously generated correct UT information should still work
when grafted onto the DATE-OBS keyword.

If the problem is that this implementor wrote some generic routine that
just divided out all of the date and time fields from one unsegmented
time argument (seconds since 1970 or whatever), and that only arguments
corresponding to even date numbers were being fed to the routine for
some reason, resulting in the 23:59:59.9 vs. 00:00:00.0 chatter around
midnight - well, this seems like an inappropriate usage.

Note that there were various discussions regarding "atomic" date/time
pairs when we were thrashing out the MJD and Y2K stuff.  Maintaining
an unsegmented time scale is a larger issue than the ISO format, and
certainly than rounding or truncation errors.

DATE-OBS specified as a variation of YYYY-MM-DDThh:mm:ss[.sss...] consists
of seven separate time segments that have to be reliably generated from
some unsegmented clock.  The fractional seconds field shouldn't just be
calculated, but should have some reality checks built into the logic.

Obviously, the simpler sexigesimal carrying and the more complicated year-
and-month dependent calendar issues have to be handled cleanly or the whole
Y2K bug will recur in some other guise.  Also, whatever TIMESYS is being
used for the date should also be used for the time information, and the
calendar and clock should be consulted simultaneously (not a trivial
computer science issue).

I would also hazard that if some software cares about the date, but not
about the time (i.e., only cares about the time to Peter's 24 hour
granularity), that a careful programmer would parse the time as well as
the date, and would round to the nearest day.  That FITS may now require
some logic tree to decide whether the time comes from DATE-OBS or UT or
whatever other keyword is just an added expense of doing FITS now that
we've added this feature of DATE-OBS.

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: sla at ucolick.borg (Steve Allen)
Date: 10 Feb 1998 15:20:08 -0800

In article <6bq7eb$l0o at post.gsfc.nasa.gov>,
>could also be a valid time string, on dates containing leap seconds.

There are few, if any, computer operating systems which implement a
correct model of time.

Therefore extreme caution should be used if new FITS date strings are
to be converted to operating system clock times using standard system
library procedures.
-- 
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.borg     Voice: +1 408 459 3046     FAX (don't): +1 408 454 9863
WWW: http://www.ucolick.borg/~sla               PGP public keys:  see WWW
Junk mail is irrelevant -- my return address has been assimilated.