<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.<br><br></div><div>Mark<br></div></div><div><br><br></div></div><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 class="">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 class=""><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_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="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Mark<br><br></div></font></span></div></div></div></div>
</blockquote></div><br></div>