Timesys note review

[Tom Donaldson]

Hi Markus, et al.,

Thanks for the thorough write-up.  I think I’m on board with the concept, and happy to help shepherd it through the VOTable change process, but I do have a few questions and comments.


  1.  In the note PDF, tables 1 and 2 are awkwardly interspersed with the content describing the TIMESYS attributes.  Even a footnote is split across two pages.



  1.  My domain knowledge on this is weak, so I will have to defer to others for the final word, but from a computing point of view, I don’t yet understand the need for the timeorigin attribute.  Is it just a convenience for values that are offsets, or is it a fundamental part of the time scale or system?



     *   If it is just a convenience, is that really necessary?  The full description of timeorigin made me pretty concerned as a client developer (i.e., I’d be disinclined to implement support for it), so I’d like to be assured that the attribute and its use are well-defined and worthwhile.



     *   Although in the astropy Time class (http://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.SCALES ) I did see clear use of time scales nearly matching those proposed here, I didn’t see any use of a time origin.  Again, this is probably just my ignorance on how times are defined and used, but:



                                                              i.      An implementation showing how those values would be used with astropy would be extraordinarily helpful to me to demonstrate the purpose and usage of timeorigin.

                                                             ii.      If the attribute is needed, I’d still need to be convinced that the convenience values JD-origin and MJD-origin are worth the added complexity.



  1.  I have never been super happy with the context-dependent meaning of “ref” (it can refer to a COOSYS, TIMEDEF, TABLE, GROUP, etc., depending on where you are, and not all the reference semantics are clear).  I realize we’re kind of stuck with that concept for now, so I’ll just ask the dumb question of whether or not a FIELD that references a TIMEDEF may also want to reference something else such as a GROUP.


Thanks for considering my questions,
Tom


From: <apps-bounces at ivoa.net> on behalf of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Date: Tuesday, December 4, 2018 at 3:52 AM
To: Applications WG <apps at ivoa.net>, "voevent at ivoa.net" <voevent at ivoa.net>
Subject: Re: Timesys note review

Hi Steve, Hi Apps,

On Thu, Nov 29, 2018 at 10:30:51AM -0800, Steve Allen wrote:
As Rob Seaman reiterates, very few observations have timestamps that
merit the distinction between UT1 and UT.  UT1 implies that some
special care has been taken in post-observation data reduction.  There
are no tabulations with self-consistent re-reductions of the
difference between UT1 and the available time signals from before the
change from FK3 catalog to FK4 catalog on 1962-01-01.

I've changed the former UT1 in that table to:

  \item[UT] Earth rotation time. We do not distinguish between UT0, UT1,
  and UT2; applications requiring this level of precision need additional
  metadata.  This should also be used to label GMT times in datasets covering
  dates before 1972-01-01.

(volute rev. 5251) and removed the former language on GMT in UTC.  Is
that minimally acceptable?

Also, I've put in François' and Mark's proposal of M?JD-origin both
into the text and the draft VOTable schema.  Putting it in convinced
me again that it's probably not a good deal in terms of standard
effort vs. possible benefit, but since nobody spoke out against it so
far, it's in now (rev. 5252).

A pre-built draft document is still at
http://docs.g-vo.org/timesys-draft.pdf, the draft schema is in volute
at
https://volute.g-vo.org/svn/trunk/projects/time-domain/timesysnote/VOTable-1.4-draft.xsd

-- unless there's more feedback, this would be what I'd submit as
version 1.1 (except I'll update the frame/refpos enumerations in the
schema).

Thanks for the feedback, everyone,

          Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/voevent/attachments/20181204/d293097b/attachment.html>