Timesys note review

[François Bonnarel]

Dear Tom, all


Le 04/12/2018 à 16:29, Tom Donaldson a écrit :
>
> 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.
>
>  2. 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?
>
>      1. 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.
>
>      2. 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.
>
TIMESYS is a VOTAble ad hoc thing gathering metadata useful for time. I 
don't discuss the name which may be misleading. Could be called TIMEMETA 
but the idea was to make it a sibling of COOSYS.

In STC terms (see the Draft sent by Mark CD a couple of days ago) a time 
frame is made of
   - time scale, reference position, reference direction.

Time representation is NOT strictly speaking part of Time Frame. But 
it's part of Time metadata. That's why it is
proposed in TIMESYS. Apart from ISOTIME, STC defines JD, MJD and 
TimeOffset for Time representation. A timeStamp (or date) in days 
without a timeorigin is undefined unless we know it is in JD or MJD.
>
>      2.   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.
>
Don't know. But I suppose Timeorigin is taken from somewhere else or 
inplicit.
>
> 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.
>
The alternative is to have two attributes : timerepresentation and 
(optional) timeorigin.
    Like this timerepresentation = JD, MJD, Offset. Then timeorigin is 
needed if timerepresentation=offset
This was my original idea.
Other authors convinced me it could be easier to group all this in the 
timeorigin attribute.
    Then two flavors.
         1 )  timeorigin = 0 or 2400000.5 or AnyDouble. for the three 
representations. This has the advantage to be managed by a double 
datatype. But doesn't clearly identify MJD or JD
         2 )  timeorigin = JD-origin, MJD-origin, or AnyDouble. this has 
the disadvantage to be coded as a string with some parsing needed, but 
clearly identifies, what is JD or MJD and what is offset.

Cheers
François

           t
>
>  3. 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/20181206/02665b28/attachment.html>