<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.<br></div><div>Mark<br><br></div></div>