<div dir="ltr"><div>Markus,<br></div>Thanks for the new vocabulary word first thing in the morning!<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 13, 2018 at 4:39 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi DM,<br>
<br>
On Thu, Apr 12, 2018 at 02:49:59PM -0400, Arnold Rots wrote:<br>
[timeOrigin as a TimeFrame; incidentally, I'd like to propose doing<br>
inline replies, as it's much easier to follow the discussion then]<br>
<span class="">> This is only an issue if time is specified as a time offset.<br>
> <br>
> The TimeFrame contains:<br>
> - a time scale<br>
> - a reference position<br>
> - a value for timeOrigin (only required if time stamps or time coordinate<br>
> values are specified as time offsets)<br>
> <br>
</span>[...]<br>
<span class="">> The timeOrigin should expressed as a TimeStamp (JD, MJD, or ISOTime, but<br>
> NOT TimeOffset),<br>
> referenced to the same TimeFrame.<br>
<br>
</span>I'd say that's a bit too apodictical. What does this complication<br>
buy us over the plain and easily implemented (i.e., less chance of<br>
bugs) specification that timeOffset (or perhaps "epoch") simply is<br>
the number of days between JD's zero point and the chosen frame's<br>
zero point in BARYCENTER? Is there any sane time scale in which that<br>
wouldn't be good enough? If there is, couldn't we just declare<br>
non-support of this in the interest of getting something workable<br>
out?<br>
<br></blockquote><div><br></div><div>Mostly I'm coming from what I've seen in the data products I've worked with.<br></div>For what I've seen, the offset has typically been given in MJD. So there seems to be a need for some flexibility here.<br><br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While we're on the topic of time representations: I still argue the<br>
serialisation of times is not a matter of the data model. Whether<br>
something is something in days, or seconds (unix timestamps!) or the<br>
whacky civil calendar is up to the serialisation and needs to be<br>
handled there. Hence, an MJD in VOTable would simply be specified<br>
using (in classic STC-in-VOTable notation):<br>
<br></blockquote><div>Typically I would agree. IF the value in MJD, JD, ISO, etc are different representations of the same TimeInstant (which is the main question here, which I haven't seen a yes|no answer about).. then it is not really on the model to distinguish between them.. a TimeInstant with value:datetime[1] is enough. <br><br>However, there is the practical side where a client has to interpret actual data. Since JD and MJD are both real numbers, there is ambiguity about how to interpret any given real number. From your example below, one could infer that the value is MJD because the timeOrigin is the JD-MJD offset. If that were not there, the client would misinterpret the value as a JD. What are the odds a provider would forget/neglect to add this static timeorigin value into the frame because their dateObs is in MJD. <br></div><div>This is why I would like to have something in the model which gives providers a way of annotating specifically.. this COL has times expressed in MJD.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<GROUP utype="stc:<wbr>CatalogEntryLocation"><br>
<PARAM arraysize="*" datatype="char" name="ReferencePosition" <br>
utype="stc:AstroCoordSystem.<wbr>TimeFrame.ReferencePosition" <br>
value="BARYCENTER"/><br>
<PARAM arraysize="*" datatype="char" name="TimeScale" <br>
utype="stc:AstroCoordSystem.<wbr>TimeFrame.TimeScale" value="TDB"/><br>
<PARAM datatype="double precision" name="TimeOffset" <br>
utype="stc:AstroCoordSystem.<wbr>TimeFrame.timeOrigin" <br>
value="2400000.5"/><br>
<FIELDref ref="COL" utype="stc:AstroCoords.Time.<wbr>TimeInstant"/><br>
[...]<br>
</GROUP><br>
<br>
<column id="COL" name="dateObs" datatype="double precision" unit="d"/><br>
<br>
Of course, this neat plan breaks down here and there; in this<br>
particular case I'd strongly suggest we include some prose of<br>
the type <br>
<br>
The use of timeOrigin is undefined for time representations that<br>
include explicit years (like 2013.143 or 2013-02-23). This model<br>
at this point only supports the Christian era and the Gregorian<br>
Calendar for such representations.<br>
<br>
Extensions for other calendar systems might come later, but at this<br>
point it would be, I argue, grossly misleading to be able to change<br>
2013-02-23 to, say, 2012-04-12T12:30:00 using the time frame.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br></div></div></div></div>