<div dir="ltr">IIRC the UTC restriction is also inherited from VOResource<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 February 2016 at 10:45, Arnold Rots <span dir="ltr"><<a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>UTC may be a DALI restriction, but time zones are specifically outlawed, both in FITS and in STC.<br></div>On an earlier comment, decimal years can simply be specified with unit='a'; but they would require an indication 'B' or 'J'.<br><br></div> - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: <a href="tel:%2B1%20617%20496%207701" value="+16174967701" target="_blank">+1 617 496 7701</a><br>60 Garden Street, MS 67 fax: <a href="tel:%2B1%20617%20495%207356" value="+16174957356" target="_blank">+1 617 495 7356</a><br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Fri, Feb 19, 2016 at 12:30 PM, Patrick Dowler <span dir="ltr"><<a href="mailto:pdowler.cadc@gmail.com" target="_blank">pdowler.cadc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>As has been discussed numerous times (!) in the past, JD and MJD are *not* types. For MJD values (eg Obscore t_min and t_max) one uses datatype="double" unit="d" and describes the coordinate system metadata using STC as Markus has described in a Note. The xtype attribute is to tell consumers of the votable that the value can be further parsed to turn it into a structure of some type, not further interpretted to mean something. I think that is an important distinction that is often ignored <br><br></div>I'm not sure about the high precision "days" + "seconds" double array. You need that in TAP only if you actually want to expose a single column with the multiple values, but I don't know off hand if anyone does that. (I will admit to having some double array vaulued columns in our TAP service; they are in a view called caom2.SIAv1 to support the coupleof columns in the SIAv1 output that are arrays... but they don't have xtypes). <br><br></div><div>Finally, the restriction of timestamps to a specific ISO8601 in UTC and without timezone comes from upstream of DALI -- VOResource iirc. It has been th accepted standard for years and DALI is only formalising some technical bit of it for usage in services like TAP, SIA2, etc<br><br></div>Emphasis: xtype tells the consumer how to further parse the value.<span><br><div><div><div><div class="gmail_extra"><br><br>-- <br><div><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div></div></div></div></span></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>