[DALI] timestamp format

[Arnold Rots]

And let me repeat:
Since astronomy has no use for time zones, but has a need
for (a) specifying time scales and (b) expressing dates and times
in formats other than JD and MJD, the ISO 8601 expression
sans the time zone specification (including the Z) makes sense
to preform (b), while (a) would be poorly served by specifying
one particular time scale (UTC) in a manner that is completely
incompatible with the way all other time scales are specified.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------



On Thu, Nov 7, 2013 at 1:30 PM, Steve Allen <sla at ucolick.org> wrote:

> On Thu 2013-11-07T09:29:31 -0800, Patrick Dowler hath writ:
> > Not sure I follow. I agree with the goal of removing tz complexity
> > from the situation I do not understand* why one would not just
> > include the Z (always) and thus actually comply to the ISO8601 spec.
> > To not include the Z, one cannot say this is a subset of ISO861,
> > where that spec says subset (profile) means "one of the allowed
> > forms, with the same meaning". What we seem to have is one of the
> > allowed forms, with a different meaning. At least that's how I read
> > the meaning/intent of ISO8601...
>
> Without digging through the archives of the FITS Y2K discussions my
> impression is that the idea was that the particular subset (and that
> use of "subset" may not mean the same thing as terms in the ISO
> document) was clear and unambiguous over the range of dates expected
> to be found in digital astronomical data sets, and also that it was
> dangerous to allow that there might be timezone information.
>
> Finally, there was also the notion that the FITS standard had to be a
> complete description on its own merits -- independent of other
> documents and standards that might change, and so there is explicitly
> no mention of ISO 8601 in the approved FITS documents.
>
> Thus I believe we had the notion that FITS DATExxxx keywords would be
> parsed by special purpose routines.  This was obviously naive and
> lacking foresight of budget-constrained futures where off-the-shelf
> APIs end up being used even when they contain features which are
> inconsistent with the FITS standard.
>
> Perhaps this application wants a footnote explaining that FITS
> DATExxxx strings are not ISO 8601, but by adding and removing
> the 'Z' when handling them they can be processed by APIs that
> expect to handle ISO 8601.
>
> --
> Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
> UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
> 1156 High Street            Voice: +1 831 459 3046           Lng
> -122.06015
> Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20131107/7f7a1bb9/attachment-0001.html>