[coords] Question - Time domain coordinates and frames

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Thu Apr 12 19:52:11 CEST 2018


All,

As I mentioned in an earlier mail, I've gotten some offline comments about
this, and have had some questions myself working example files.

The attached image shows the relevant elements from the coords model.
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.

Example:
   Say I have a data value: T = 342289.7 d
   Is this:
     a) a MJD date
     b) a JD date
     c) an offset from some random reference time, in units of days.
   The requirement on the model is to be able to distinguish/specify which.

Cases:
   In the example cases we are working, there are the following variations
(among others)
   1) the GAIA time series.
        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."

  2) for the Chandra event list, we have Time expressed in seconds (mission
elapsed time).
        An offset in seconds from a reference date (given by an MJD date;
eg: 50814.0)

  3) ordinary 'DATE' strings
        eg: "2010-01-01T00:00:00"

Questions:
   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)?".
        As it is here, we are changing frames, and I think this is the root
of the problem.
       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.

       If this were the case, we would only need
       a) TimeInstant with time:datetime,   datetime would need to be able
to express the value in various flavors ( ISO, JD, MJD )
       b) TimeOffset with time:RealQuantity + time0:TimeStamp  to provide
the reference date (which could be in a different frame)

   2) If we go with the above, how does a provider specify what 'flavor' a
particular value is currently in?
       In other words, we need something in the model that distinguishes
flavors.
        "This PARAM with value=342289.7 unit='d' is a TimeInstant expressed
as an MJD date."
       a) an enumeration of flavors added to TimeInstant.. basically the
formats that datetime can express
       b) a set of subclasses of TimeInstant for each flavor ( but
otherwise empty ), this would let the Type identify the flavor.
           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.

    3) If the answer to 1) is 'No'.. this is a frame change.. then how do
we end the recursion?
         + JD pointing to Frame with no time0 == 'standard' Julian Date
         + JD pointing to Frame with time0 == 'non-standard' Julian Date
               ** could this be confusing for applications which need to
check the frame before interpreting the JD type?

    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.
Is this OK?


Sorry for the long message.. looking forward to hearing your thoughts.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20180412/dbe80d7b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: time snippet.png
Type: image/png
Size: 15025 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20180412/dbe80d7b/attachment-0001.png>


More information about the dm mailing list