<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi all,</p>
<p>My understanding of this:</p>
<p> - If Time representation is JD, MJD or ISO we don't need any
TimeOrigin (the origin is included in the definition)</p>
<p> - In case of TimeOffset, the TimeOrigin has to be given in
some representation of time, but with the same TimeScale and
Refpostion than the Frame it is included i</p>
<p> - In STC JD, MJD, TimeOffset are subclasses of TimeInstant.
They are not attributes. So I wil slightly rephrase Marku's
example this way</p>
<p> <GROUP utype="stc:</p>
<blockquote class="gmail_quote"><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="TimeOrigin" <br>
utype="stc:AstroCoordSystem.<wbr>TimeFrame.timeOrigin.JD"
<br>
value="2400000.5"/><br>
---> Obviously the name here was not TimeOffset but
TimeOrigin. TimeOrigin is containing a TimeStamp, here it is in
JD.<br>
<FIELDref ref="COL" utype="stc:AstroCoords.Time.<wbr>TimeOffset"/><br>
---> TimeInstant (or TimeStamp) will be a of "TimeOffset" Type
of repressentation in the corresponding column<br>
[...]<br>
</GROUP><br>
<br>
<FIELD id="COL" name="dateObs" datatype="double precision"
unit="d"/><br>
--->Replacing column by FIELD<br>
</blockquote>
<br>
Cheers<br>
François<br>
<div class="moz-cite-prefix">Le 13/04/2018 à 14:50,
CresitelloDittmar, Mark a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAH4enyNRB5gRyGw8D2JFQGKh2rB+mtU0FeHMaQ+zrqx0_SDXHA@mail.gmail.com">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">msdemlei@ari.uni-heidelberg.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote">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">
<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">
<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"><br>
-- Markus<br>
</span></blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>