Timesys note review

Mon Dec 10 18:34:35 CET 2018

Hi all,

Just to illustrate the context, I did a short survey of the time column 
definitions found in VizieR. Here the result of my quick view for an 
half hundred of random tables (selected by UCD time.epoch). As you can 
see, we get a lot of various timeoffsets, generally based on JD origin, 
and MJD (<=> timeOffset:2400000.5) is just one case among others. We 
also find decimal years, with or without offset. And very few calendar 
date (ISO or others)

Cheers
Pierre

 1. *JD *(19x) [CDS/I/337/rrlyrae, CDS/VI/44/catalog,
    CDS/J/A+A/459/321/table4, CDS/J/AcA/54/207/table1,
    CDS/J/AcA/49/223/lmc_sc, CDS/J/AcA/49/437/smc_sc,
    CDS/J/AcA/48/563/smc_sc, CDS/J/AJ/133/1470/tsvsc1,
    CDS/J/ApJ/781/22/table1, CDS/J/ApJS/225/9/table2,
    CDS/J/ApJS/217/18/table1, CDS/J/ApJS/208/16/koi,
    CDS/J/MNRAS/447/3342/table3a, CDS/J/MNRAS/447/3342/table3b,
    CDS/J/other/IBVS/5721/table3, CDS/J/other/JAVSO/37.169/nsvs,
    CDS/J/PASP/123/412/table1, CDS/II/213/pvar]
 2. *MJD *(11x) [CDS/B/psr/psr, CDS/J/AJ/152/158/table3,
    CDS/J/AJ/146/21/table1, CDS/J/AJ/144/93/table,
    CDS/J/AJ/142/160/table3, CDS/J/AJ/142/160/v3,
    CDS/J/ApJS/217/31/KOIs, CDS/J/MNRAS/441/1230/catalog,
    CDS/J/other/IBVS/5969/nl80, CDS/II/340/summary,
    CDS/J/A+A/619/A50/catalog]
 3. *JD timeOffset: 2450000.0* (9x) [CDS/J/AcA/63/323/ecl,
    CDS/J/AcA/60/1/catalog, CDS/J/AcA/60/17/catalog,
    CDS/J/AcA/58/163/catalog, CDS/J/AcA/54/1/table2, CDS/J/AcA/53/1/eb,
    CDS/J/AcA/53/93/catalog, CDS/J/AJ/151/68/catalog,
    CDS/J/MNRAS/443/432/HEBs]
 4. *YEARS timeOffset 1900 *(5x) [CDS/J/A+A/509/A3/eoc4,
    CDS/I/149A/catalog, CDS/I/180/gcpa, CDS/I/128/data, CDS/I/206/ppmb]
 5. *YEARS* [CDS/J/AJ/153/95/table3, CDS/J/AJ/150/107/table1,
    CDS/J/ApJ/807/170/table2, CDS/J/ApJ/756/185/table1, CDS/I/188/pmc88,
    CDS/I/121/cpm, CDS/I/78/catalog, CDS/J/A+A/618/A44/tablea7]
 6. *JD timeOffset: 2454900.0* (3x)[CDS/J/AJ/151/110/table1,
    CDS/J/ApJS/210/19/table1, CDS/J/ApJS/197/2/table2]
 7. **DATE "Y:M:D"* *(3x) [CDS/J/ApJS/235/5/table2,
    CDS/J/ApJS/235/5/table3, CDS/VI/25/nposs]
 8. *JD timeOffset: 2400000.0* (2x) [CDS/J/AJ/141/83/table1,
    CDS/J/ApJ/663/249/table1]
 9. *JD timeOffset: 2454800.0* (1x) [CDS/J/ApJ/773/54/table1]
10. *JD timeOffset: 2454833* (1x) [CDS/J/ApJS/199/24/table1]
11. *JD timeOffset: **2454000***(1x)**[CDS/J/MNRAS/429/2001/table2]
12. *YEARS timeOffset 1800 * (1x) [CDS/I/310/agk1]
13. *DATE 'Y-M-D"* (1x) [CDS/II/283/sncat]
14. *DATE "MMMYY"* (1x) [CDS/II/218/sn]
15. *ISOTIME * (1x) [CDS/J/A+A/619/L3/list]
16. *Dedicated code* (1x) (R0 =RA, DEC in the J2000 coordinates, R5 =RA,
    DEC in the 1950 coordinates ) [CDS/V/150/variabls, ]

Le 06/12/2018 à 12:03, Mark Taylor a écrit :
> On Wed, 5 Dec 2018, Markus Demleitner wrote:
>
>> On Tue, Dec 04, 2018 at 03:29:31PM +0000, Tom Donaldson wrote:
>>
>>>   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.
>> Since I'd rather not have them either, I'd say those who want them
>> should again make their points. The one thing almost making me like
>> them is that it's easy to say 240000.5 instead of 2400000.5, whereas
>> NJD-origin is easily caught.
> Really just human-friendliness: readability, writability,
> comprehensibility.  While I don't think that VOTable is or should
> be mostly a human-readable format, there will inevitably be
> human eyes on this from time to time, including when writing
> [the code to write] these elements.  If you see:
>
>     <TIMESYS ID="_tframe" refposition="BARYCENTER" timescale="TCB"
>              timeorigin="JD-origin"/>
>     ...
>       <FIELD ID="obs_time" datatype="double" name="obs_time" ref="_tframe"/>
>
> it's really obvious what's going on, even if you've never heard of
> the TIMESYS element.  If instead you see timeorigin="0" you're
> definitely going to have to locate and read the document describing
> this element to work out if the reference is to JD, MJD, Unix epoch etc.
> (I admit that if you see timeorigin="2400000.5" you've probably got
> a good chance of guessing right).  And also the typo thing that
> Markus notes.
>
> To me the cost, namely additional complication in the XSD and in
> parsing code, is not very high.  As somebody implementing code
> that may have to understand this, it certainly doesn't worry me,
> in terms of additional code complexity or likely bug opportunities,
> to put a couple of special cases in the parser for these
> numerical aliases.
>
> I initially thought that having aliases for JD and MJD would cover
> a large fraction of the tables that need to use TIMESYS, however Ada,
> who I don't doubt has a much better idea about this, said not
> (http://mail.ivoa.net/pipermail/apps/2018-November/001316.html).
> If usage of these named time origins is really not very common,
> that would weaken the case for it.  And if most people don't like it
> in any case, so be it.  But I still think it's a good idea.
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

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