<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Dear Tom, all<br>
</p>
<br>
<div class="moz-cite-prefix">Le 04/12/2018 à 16:29, Tom Donaldson a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:F19C0E69-1EB1-4D84-BE48-003A9580E504@stsci.edu">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<div class="WordSection1">
<p class="MsoNormal"><span>Hi Markus, et al.,</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Thanks for the thorough write-up. I
think I’m on board with the concept, and happy to help
shepherd it through the VOTable change process, but I do
have a few questions and comments.</span></p>
<p class="MsoNormal"><span> </span></p>
<ol start="1" type="1">
<li class="MsoListParagraph"><span>In the note PDF, tables 1
and 2 are awkwardly interspersed with the content
describing the TIMESYS attributes. Even a footnote is
split across two pages.</span></li>
</ol>
<p class="MsoListParagraph"><span> </span></p>
<ol start="2" type="1">
<li class="MsoListParagraph"><span>My domain knowledge on this
is weak, so I will have to defer to others for the final
word, but from a computing point of view, I don’t yet
understand the need for the timeorigin attribute. Is it
just a convenience for values that are offsets, or is it a
fundamental part of the time scale or system?
</span></li>
</ol>
<p class="MsoListParagraph"><span> </span></p>
<ol start="2" type="1">
<ol start="1" type="a">
<li class="MsoListParagraph"><span>If it is just a
convenience, is that really necessary? The full
description of timeorigin made me pretty concerned as a
client developer (i.e., I’d be disinclined to implement
support for it), so I’d like to be assured that the
attribute and its use are well-defined and worthwhile.</span></li>
</ol>
</ol>
<p class="MsoListParagraph"><span> </span></p>
<ol start="2" type="1">
<ol start="2" type="a">
<li class="MsoListParagraph"><span>Although in the astropy
Time class (<a
href="http://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.SCALES"
moz-do-not-send="true">http://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.SCALES</a>
) I did see clear use of time scales nearly matching
those proposed here, I didn’t see any use of a time
origin.</span></li>
</ol>
</ol>
</div>
</blockquote>
TIMESYS is a VOTAble ad hoc thing gathering metadata useful for
time. I don't discuss the name which may be misleading. Could be
called TIMEMETA but the idea was to make it a sibling of COOSYS.<br>
<br>
In STC terms (see the Draft sent by Mark CD a couple of days ago) a
time frame is made of<br>
- time scale, reference position, reference direction.<br>
<br>
Time representation is NOT strictly speaking part of Time Frame. But
it's part of Time metadata. That's why it is <br>
proposed in TIMESYS. Apart from ISOTIME, STC defines JD, MJD and
TimeOffset for Time representation. A timeStamp (or date) in days
without a timeorigin is undefined unless we know it is in JD or MJD.<br>
<blockquote type="cite"
cite="mid:F19C0E69-1EB1-4D84-BE48-003A9580E504@stsci.edu">
<div class="WordSection1">
<ol start="2" type="1">
<ol start="2" type="a">
<li class="MsoListParagraph"><span> Again, this is probably
just my ignorance on how times are defined and used,
but:</span></li>
</ol>
</ol>
<p class="MsoListParagraph"><span> </span></p>
<p class="MsoListParagraph">
<span><span><span>
</span>i.<span> </span></span></span><span>An
implementation showing how those values would be used with
astropy would be extraordinarily helpful to me to
demonstrate the purpose and usage of timeorigin.</span></p>
</div>
</blockquote>
Don't know. But I suppose Timeorigin is taken from somewhere else or
inplicit.<br>
<blockquote type="cite"
cite="mid:F19C0E69-1EB1-4D84-BE48-003A9580E504@stsci.edu">
<div class="WordSection1">
<p class="MsoListParagraph">
<span><span><span>
</span>ii.<span> </span></span></span><span>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.</span></p>
</div>
</blockquote>
The alternative is to have two attributes : timerepresentation and
(optional) timeorigin. <br>
Like this timerepresentation = JD, MJD, Offset. Then timeorigin
is needed if timerepresentation=offset<br>
This was my original idea.<br>
Other authors convinced me it could be easier to group all this in
the timeorigin attribute.<br>
Then two flavors.<br>
1 ) timeorigin = 0 or 2400000.5 or AnyDouble. for the three
representations. This has the advantage to be managed by a double
datatype. But doesn't clearly identify MJD or JD<br>
2 ) timeorigin = JD-origin, MJD-origin, or AnyDouble. this
has the disadvantage to be coded as a string with some parsing
needed, but clearly identifies, what is JD or MJD and what is
offset. <br>
<br>
Cheers<br>
François<br>
<br>
t <br>
<blockquote type="cite"
cite="mid:F19C0E69-1EB1-4D84-BE48-003A9580E504@stsci.edu">
<div class="WordSection1">
<p class="MsoListParagraph"><span> </span></p>
<ol start="3" type="1">
<li class="MsoListParagraph"><span>I have never been super
happy with the context-dependent meaning of “ref” (it can
refer to a COOSYS, TIMEDEF, TABLE, GROUP, etc., depending
on where you are, and not all the reference semantics are
clear). I realize we’re kind of stuck with that concept
for now, so I’ll just ask the dumb question of whether or
not a FIELD that references a TIMEDEF may also want to
reference something else such as a GROUP.</span></li>
</ol>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Thanks for considering my questions,</span></p>
<p class="MsoNormal"><span>Tom</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span> </span></p>
<div>
<p class="MsoNormal"><b><span>From:
</span></b><span><a class="moz-txt-link-rfc2396E" href="mailto:apps-bounces@ivoa.net"><apps-bounces@ivoa.net></a> on behalf
of Markus Demleitner
<a class="moz-txt-link-rfc2396E" href="mailto:msdemlei@ari.uni-heidelberg.de"><msdemlei@ari.uni-heidelberg.de></a><br>
<b>Date: </b>Tuesday, December 4, 2018 at 3:52 AM<br>
<b>To: </b>Applications WG <a class="moz-txt-link-rfc2396E" href="mailto:apps@ivoa.net"><apps@ivoa.net></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:voevent@ivoa.net">"voevent@ivoa.net"</a> <a class="moz-txt-link-rfc2396E" href="mailto:voevent@ivoa.net"><voevent@ivoa.net></a><br>
<b>Subject: </b>Re: Timesys note review</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Hi Steve, Hi Apps,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">On Thu, Nov 29, 2018 at 10:30:51AM -0800,
Steve Allen wrote:</p>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<p class="MsoNormal">As Rob Seaman reiterates, very few
observations have timestamps that</p>
</div>
<div>
<p class="MsoNormal">merit the distinction between UT1 and
UT. UT1 implies that some</p>
</div>
<div>
<p class="MsoNormal">special care has been taken in
post-observation data reduction. There</p>
</div>
<div>
<p class="MsoNormal">are no tabulations with self-consistent
re-reductions of the</p>
</div>
<div>
<p class="MsoNormal">difference between UT1 and the
available time signals from before the</p>
</div>
<div>
<p class="MsoNormal">change from FK3 catalog to FK4 catalog
on 1962-01-01.</p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I've changed the former UT1 in that table
to:</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> \item[UT] Earth rotation time. We do
not distinguish between UT0, UT1,</p>
</div>
<div>
<p class="MsoNormal"> and UT2; applications requiring this
level of precision need additional</p>
</div>
<div>
<p class="MsoNormal"> metadata. This should also be used to
label GMT times in datasets covering
</p>
</div>
<div>
<p class="MsoNormal"> dates before 1972-01-01.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">(volute rev. 5251) and removed the former
language on GMT in UTC. Is</p>
</div>
<div>
<p class="MsoNormal">that minimally acceptable?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Also, I've put in François' and Mark's
proposal of M?JD-origin both</p>
</div>
<div>
<p class="MsoNormal">into the text and the draft VOTable
schema. Putting it in convinced</p>
</div>
<div>
<p class="MsoNormal">me again that it's probably not a good
deal in terms of standard</p>
</div>
<div>
<p class="MsoNormal">effort vs. possible benefit, but since
nobody spoke out against it so</p>
</div>
<div>
<p class="MsoNormal">far, it's in now (rev. 5252).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">A pre-built draft document is still at</p>
</div>
<div>
<p class="MsoNormal"><a
href="http://docs.g-vo.org/timesys-draft.pdf"
moz-do-not-send="true">http://docs.g-vo.org/timesys-draft.pdf</a>,
the draft schema is in volute</p>
</div>
<div>
<p class="MsoNormal">at</p>
</div>
<div>
<p class="MsoNormal"><a
href="https://volute.g-vo.org/svn/trunk/projects/time-domain/timesysnote/VOTable-1.4-draft.xsd"
moz-do-not-send="true">https://volute.g-vo.org/svn/trunk/projects/time-domain/timesysnote/VOTable-1.4-draft.xsd</a></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">-- unless there's more feedback, this
would be what I'd submit as</p>
</div>
<div>
<p class="MsoNormal">version 1.1 (except I'll update the
frame/refpos enumerations in the</p>
</div>
<div>
<p class="MsoNormal">schema).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks for the feedback, everyone,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> Markus</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
<br>
</body>
</html>