A Proposal for a TIMESYS Element in VOTable
AdaNebot
ada.nebot at astro.unistra.fr
Fri Nov 9 21:29:44 CET 2018
Hi again Arnold,
I propose we move any further discussion to apps.
Cheers,
Ada
> On 9 Nov 2018, at 21:15, AdaNebot <ada.nebot at astro.unistra.fr> wrote:
>
> Hi Arnold,
>
> Sorry for the late and long reply.
>> On 1 Nov 2018, at 20:37, Arnold Rots <arots at cfa.harvard.edu <mailto:arots at cfa.harvard.edu>> wrote:
>>
>> I maintain that the better way to indicate the actual time stamp value (i.e., not the TIMESYS) is to use well established representations.
>> Both JD and MJD are officially recognized by the IAU, while the limited ISO-8601 is a convenient user-friendly representation that has the blessing of the ISO.
>> I grant you that a fourth representation, elapsed time (the only one that requires a unit), is needed and that it requires a time origin, but it is a bit silly to require a time origin for an officially recognized representation like MJD.
>
> I see your point, and this is something we thought about. JD and MJD are clear definitions, with a well defined origin. In this proposal, by setting the time origin to be in JD we set a unique reference for time (one of the representations officially recognised by IAU), which in my opinion makes it easier to combine data coming from different data providers. Time origin is particularly important for those cases where a random time has been subtracted from the data to have enough precision or because there was in interesting event happening at a certain date and this makes the reference for further observations.
> One can argue the problem is in the side of the data providers who would have to collect these random numbers. But to my knowledge, data providers are already collecting this information in one way or another and formalising the way the data can be annotated can only help interoperability.
>
> Perhaps other people would like to mention their point of view here. Application developers and data providers should mention their point of view and concerns if they have them. But, we don’t foresee any problems in implementation if the proposed annotation would be accepted.
>
>> So, I would suggest adding to TIMESYS an attribute like origintype=JD|MJD|ISO and to the timestamp an attribute like timetype=JD|MJD|ISO|ELAPSED and requiring the timeorigin and the unit only to be present for timetype=ELAPSED.
>
> I agree this is more in line with STC, although not following the exact names proposed by it. And I think that a full representation has it’s place in a model. In the proposed TIMESYS element we would like to keep things as simple as possible, of course without loosing any important bit of information. And it will be compatible with any proposed serialisation mapped from a model, in the sense that the annotation proposed here will not conflict with further annotation.
>
>
> We explicitly mention that distinction between times given as a floating point value (e.g., JD, julian or besselian years, unix times) and as civil dates is already effected by VOTable and the DALI timestamp xtype (Dowler and Demleitner et al., 2017). If further time representations ever appeared desirable (e.g., SOFA's high-precision times stored in two double precision floating-point values), they would probably be described with further xtypes in DALI.
> As for units, they are covered by the existing VOTable standard (Ochsenbein and Taylor et al., 2013) and the ancillary VOUnits standard (Derriere and Gray et al., 2014).
> As long as these standards are followed, no interoperability problems are foreseen regardless of whether times are given in years, days, seconds or any derivation of them.
>
>> For one thing, this is consistent with FITS WCS usage.
>>
>
>> I was puzzled by the very last example of Section 3. It claims to provide a time stamp in MJD, but it is actually provided as ISO-8601.
>
> This was a complete error from our side. Thanks for spotting it.
>
> Here is what this should have looked like:
>
> <TIMESYS refposition="TOPOCENTER" timescale="TT" timeorigin="2400000.5"
> ID="_MJD"/>
> <PARAM ref="_MJD" name="epoch" datatype="double"
> value="58424.37”/>
>
> We would like to collect some other examples for specific missions as distributed by different data providers.
> The case that come immediately to my mind in Gaia:
> Gaia as could be distributed by ESAC:
> <TIMESYS refposition="BARYCENTER" timescale="TCB" timeorigin=“2455197.5”/>
>
> Gaia as could be distributed by GAVO:
> <TIMESYS refposition="BARYCENTER" timescale="TCB" timeorigin=“0”/>
>
> Gaia as could be distributed by VizieR:
> <TIMESYS refposition="BARYCENTER" timescale="TCB" timeorigin=“2455197.5”/>
>
> Note that GAVO adds the time origin to the data, and therefore it’s value in TIMESYS for timeorigin is 0.
>
> At the moment, this is what is stated in the Gaia DR2 light-curves:
> Different times are defined for each band. For G, it is the field-of-view transit averaged observation time. For BP and RP, it is the observation time of the BP CCD transit. The units are Barycentric JD (in TCB) in days -2,455,197.5, computed as follows. First the observation time is converted from On-board Mission Time (OBMT) into Julian date in TCB (Temps Coordonnee Barycentrique). Next a correction is applied for the light-travel time to the Solar system barycentre, resulting in Barycentric Julian Date (BJD). Finally, an offset of 2,455,197.5 days is applied (corresponding to a reference time $T_0$ at 2010-01-01T00:00:00) to have a conveniently small numerical value. Although the centroiding time accuracy of the individual CCD observations is (much) below 1~ms (e.g. in BP and RP), the G band observation time is averaged over typically 9 CCD observations taken in a time range of about 44sec.
>
> To summarise, I think the TIMESYS presented in the Note allows for a compact easy way of annotating time in VOTable and allowing interoperability.
>
> I would like to collect a few more examples and update the Note correspondingly. We will also take into account the new definition of TAI after recommendation by the BIPM.
>
>>
>> Finally, I am not really happy with the choice of the name TIMESYS, as this is used in FITS WCS with a different meaning. TIMEFRAME might be a better choice.
>>
>
> The name was used in line with COOSYS, no other reason behind it.
>
> Cheers,
> Ada
>
>> 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 <mailto:arots at cfa.harvard.edu>
>> USA http://hea-www.harvard.edu/~arots/ <http://hea-www.harvard.edu/~arots/>
>> --------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> On Wed, Oct 31, 2018 at 9:25 AM AdaNebot <ada.nebot at astro.unistra.fr <mailto:ada.nebot at astro.unistra.fr>> wrote:
>> Dear All,
>>
>> A Note entitled “A Proposal for a TIMESYS Element in VOTable” can be found under:
>>
>> http://ivoa.net/documents/Notes/TimeSys/ <http://ivoa.net/documents/Notes/TimeSys/>
>>
>>
>> Thanks for taking the time to read this document,
>>
>> Happy reading!
>>
>> See you in College Park,
>> Ada Nebot
>> TDIG Chair
>
>
>> On 1 Nov 2018, at 20:37, Arnold Rots <arots at cfa.harvard.edu <mailto:arots at cfa.harvard.edu>> wrote:
>>
>> I maintain that the better way to indicate the actual time stamp value (i.e., not the TIMESYS) is to use well established representations.
>> Both JD and MJD are officially recognized by the IAU, while the limited ISO-8601 is a convenient user-friendly representation that has the blessing of the ISO.
>> I grant you that a fourth representation, elapsed time (the only one that requires a unit), is needed and that it requires a time origin, but it is a bit silly to require a time origin for an officially recognized representation like MJD.
>>
>> So, I would suggest adding to TIMESYS an attribute like origintype=JD|MJD|ISO and to the timestamp an attribute like timetype=JD|MJD|ISO|ELAPSED and requiring the timeorigin and the unit only to be present for timetype=ELAPSED.
>>
>> For one thing, this is consistent with FITS WCS usage.
>>
>> I was puzzled by the very last example of Section 3. It claims to provide a time stamp in MJD, but it is actually provided as ISO-8601.
>>
>> Finally, I am not really happy with the choice of the name TIMESYS, as this is used in FITS WCS with a different meaning. TIMEFRAME might be a better choice.
>>
>> 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 <mailto:arots at cfa.harvard.edu>
>> USA http://hea-www.harvard.edu/~arots/ <http://hea-www.harvard.edu/~arots/>
>> --------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> On Wed, Oct 31, 2018 at 9:25 AM AdaNebot <ada.nebot at astro.unistra.fr <mailto:ada.nebot at astro.unistra.fr>> wrote:
>> Dear All,
>>
>> A Note entitled “A Proposal for a TIMESYS Element in VOTable” can be found under:
>>
>> http://ivoa.net/documents/Notes/TimeSys/ <http://ivoa.net/documents/Notes/TimeSys/>
>>
>>
>> Thanks for taking the time to read this document,
>>
>> Happy reading!
>>
>> See you in College Park,
>> Ada Nebot
>> TDIG Chair
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20181109/438e78ae/attachment-0001.html>
More information about the apps
mailing list