<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>This is only an issue if time is specified as a time offset.<br><br></div>The TimeFrame contains:<br></div>- a time scale<br></div>- a reference position<br></div>- a value for timeOrigin (only required if time stamps or time coordinate values are specified as time offsets)<br><br></div>[there are a few other optional attributes (solar system ephemeris, reference direction, period), but these are not relevant in this context]<br><br></div>The time stamp can be specified as:<br></div>JD (no units required)<br></div>MJD (no units required)<br></div>ISO-8601 (no units required)<br>TimeOffset (units required, as well as a value for timeOrigin in the frame)<br></div><br></div>The timeOrigin should expressed as a TimeStamp (JD, MJD, or ISOTime, but NOT TimeOffset),<br></div>referenced to the same TimeFrame.<br><br></div>So, yes, this is recursive, but there are strict constraints on the timeOrigin which should prevent runaway looping.<br><br></div>There are no non-standard JDs or MJDs.<br></div>JD and MJD have a an absolute meaning.<br></div>Anything else requires a unit (d or s, most likely) and a specific timeOrigin, expressed in one of the absolute time stamps JD, MJD, or ISOTime.<br></div>No flavors are required here and don't muddy the waters with fancy-sounding, but ill-defined, names.<br></div>A Barycentric Julian Date is an oxymoron.<br></div>A Julian Day referenced to a TimeFrame with refPosition=BARYCENTER and timeScale=TDB is probably what is intended.<br><br></div>So, if that is the correct interpretation, the Gaia example uses:<br>a TimeStamp of the kind TimeOffset with unit 'd', referenced to a TimeFrame specified as:<br></div>timeScale = TDB<br></div>refPosition = BARYCENTER<br></div>timeOrigin = (ISOTIME) 2010-01-01T00:00:00<br></div><div>[since it is barycentric, it also needs a reference direction and a solar system ephemeris]<br></div><div><br></div>Chandra uses a TimeStamp of the kind TimeOffset with unit 's', referenced to a TimeFrame specified as:<br></div>timeScale = TT<br></div>refPosition = TOPOCENTER<br></div>timeOrigin = (MJD) 50814.0<br><br></div>"Ordinary" date strings (whatever that means) appear to be TimeStamps of the kind ISOTime,<br></div>but still need to be referenced to a TimeFrame containing a timeScale and a refPosition.<br><br></div>You will find all this also described in the Time 101 email I sent around last year (or so).<br><br></div>Cheers,<br><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 Thu, Apr 12, 2018 at 1:52 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>All,<br><br></div>As I mentioned in an earlier mail, I've gotten some offline comments about this, and have had some questions myself working example files.<br><br></div>The attached image shows the relevant elements from the coords model.<br></div><div>You'll see that the TimeFrame contains a time0 which identifies the zero point of this frame. That is given by a TimeStamp, which in turn would have a reference to a TimeFrame, which generates a bit of a recursion.<br><br></div><div>Example:<br></div><div> Say I have a data value: T = 342289.7 d<br></div><div> Is this:<br></div><div> a) a MJD date<br></div><div> b) a JD date<br></div><div> c) an offset from some random reference time, in units of days.<br></div> The requirement on the model is to be able to distinguish/specify which.<br><br></div>Cases:<br></div> In the example cases we are working, there are the following variations (among others) <br>
<div><div><div><div><div> 1) the GAIA time series.<br></div><div>
Describes it's time data as Barycentric Julian Date "with an offset of
2,455,197.5 days (corresponding to a reference time T0 at
2010-01-01T00:00:00) to have a conveniently small numerical value."<br></div><br></div> 2) for the Chandra event list, we have Time expressed in seconds (mission elapsed time).<br></div> An offset in seconds from a reference date (given by an MJD date; eg: 50814.0)<br></div><br></div><div> 3) ordinary 'DATE' strings<br></div><div> eg: "2010-01-01T00:00:00"<br></div><div><br></div><div>Questions:<br></div><div> 1) The primary question is "are ISOTime, JD, and MJD the same thing? or are we changing frames when we go from JD to MJD (for example)?".<br></div><div> As it is here, we are changing frames, and I think this is the root of the problem.<br></div><div> Astropy seems to take the approach that they are simply different representations of the same date. The important bit from the frame is mainly the timescale. So, we'd get different frames only if the scale or reference position changes.<br><br></div><div> If this were the case, we would only need<br></div><div> a) TimeInstant with time:datetime, datetime would need to be able to express the value in various flavors ( ISO, JD, MJD )<br></div><div> b) TimeOffset with time:RealQuantity + time0:TimeStamp to provide the reference date (which could be in a different frame)<br><br></div><div> 2) If we go with the above, how does a provider specify what 'flavor' a particular value is currently in?<br></div><div> In other words, we need something in the model that distinguishes flavors.<br></div><div> "This PARAM with value=342289.7 unit='d' is a TimeInstant expressed as an MJD date."<br></div><div> a) an enumeration of flavors added to TimeInstant.. basically the formats that datetime can express<br></div><div> b) a set of subclasses of TimeInstant for each flavor ( but otherwise empty ), this would let the Type identify the flavor.<br></div><div> NOTE: I think this may be very close to an earlier version that Arnold had.. and STC1 for that matter, which I argued against because there is an obvious origin shift between MJD and JD which is a key factor in identifying a frame change.<br></div><div> <br></div><div> 3) If the answer to 1) is 'No'.. this is a frame change.. then how do we end the recursion?<br></div><div> + JD pointing to Frame with no time0 == 'standard' Julian Date<br></div><div> + JD pointing to Frame with time0 == 'non-standard' Julian Date<br></div><div> ** could this be confusing for applications which need to check the frame before interpreting the JD type?<br><br></div><div> 4) again, if the answer to 1) is 'Yes'.. then the GAIA time example (JD with random offset to make a nice number), would be a TimeOffset, not a TimeInstant. ie: the values would be RealQuantity, you could create a TimeInstant from the value+offset pair.<br></div><div>Is this OK?<br><br><br></div><div>Sorry for the long message.. looking forward to hearing your thoughts.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Mark<br><br></div></font></span></div>
</blockquote></div><br></div>