<div dir="ltr"><div><div><div>We keep rehashing the same arguments - this is something we hashed out several years ago.<br></div>In the spatial frames the origin is included in the frame class.<br></div>Then it makes sense to include the time origin (for a time offset axis) also in the time frame.<br><br></div><div>The difference is simply that for time we have, in addition, three ways to specify a time stamp that don't need an origin.<br></div><div><br></div> - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<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>
<br><div class="gmail_quote">On Fri, Apr 13, 2018 at 5:03 PM, CresitelloDittmar, Mark <span dir="ltr"><<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@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><div><div><div><div><div>All,<br><br></div>So, (again depending on what constitutes a Frame change in the time domain). If we change the model a bit (see attached image). We can remove the recursive problem, accommodate the annotation of particular 'real' values in data, and allow for the variations on JD/MJD that Paul alluded to. It is NOT as rigid in the ISOTime. With this model, origin changes in Frame would be more on the Calendar level.. and I agree with Markus that we could make a statement that we are supporting Gregorian, other systems can follow.<br></div></div><br></div><div>The change basically puts the Frame relation to a specific moment in time, that being represented by an absolute TimeInstant:(JD/MJD/ISO) or a relative TimeOffset. The TimeOffset, provides the zero point as TimeInstant + value for time since then.<br></div><br></div>I'm also including some example serializations to show the mapping. These use the current vo-dml/mapping syntax.<br></div><div>The "_alt" versions use this diagram, the others are from the current model.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Mark<br></div></font></span></div><div><br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 13, 2018 at 9:04 AM, CresitelloDittmar, Mark <span dir="ltr"><<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@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">One more point on this:<br><div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Apr 12, 2018 at 5:18 PM, 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><div><div><div>No, the timeOrigin is only REQUIRED in a TimeFrame if it is referenced by a TimeOffset.<br></div>So, <b>both the TimeOffset and the timeOrigin can (and should!) refer to the same TimeFrame</b>.<br></div>(they should, because specifying the origin in a different TimeFrame is asking for trouble)<br><br></div></div></div></div></blockquote><div><br></div></span><div>What I'm taking away from this is:<br></div><div> + TimeOffset and TimeOrigin are in the same Frame..<br></div><div> + the TimeOffset has/requires a timeOrigin<br></div><div> + the TimeOrigin should ignore the timeOrigin<br><br></div><div>From this, I would have to conclude that the timeOrigin is a property of the TimeOffset, not the Frame.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>It does mean that TimeOffsets that use different timeOrigins need to reference different TimeFrames.<br></div>That is not a problem, since most TimeOffset-based time series will use the same timeOrigin.<span class="m_-2168901009404882242m_1879391666367442961HOEnZb"><font color="#888888"><br></font></span></div></div></blockquote><div><br></div></span><div>The question is more if they are <b>considered </b>to be in the same frame.<br></div><div>If I have 2 TimeOffsets, T1 and T2, both in "TDB", "BARYCENTER"... are they in the same frame? even if they have different offsets?<span class="m_-2168901009404882242HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_-2168901009404882242HOEnZb"><font color="#888888"><div>Mark<br><br></div></font></span></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>