A warning for FITS y2k implementors

[Rob Seaman]

Peter Bunclark <psb at ast.cam.ac.uk> writes:

> 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!

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