[coords] Question - Time domain coordinates and frames

[Arnold Rots]

This is only an issue if time is specified as a time offset.

The TimeFrame contains:
- a time scale
- a reference position
- a value for timeOrigin (only required if time stamps or time coordinate
values are specified as time offsets)

[there are a few other optional attributes (solar system ephemeris,
reference direction, period), but these are not relevant in this context]

The time stamp can be specified as:
JD (no units required)
MJD (no units required)
ISO-8601 (no units required)
TimeOffset (units required, as well as a value for timeOrigin in the frame)

The timeOrigin should expressed as a TimeStamp (JD, MJD, or ISOTime, but
NOT TimeOffset),
referenced to the same TimeFrame.

So, yes, this is recursive, but there are strict constraints on the
timeOrigin which should prevent runaway looping.

There are no non-standard JDs or MJDs.
JD and MJD have a an absolute meaning.
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.
No flavors are required here and don't muddy the waters with
fancy-sounding, but ill-defined, names.
A Barycentric Julian Date is an oxymoron.
A Julian Day referenced to a TimeFrame with refPosition=BARYCENTER and
timeScale=TDB is probably what is intended.

So, if that is the correct interpretation, the Gaia example uses:
a TimeStamp of the kind TimeOffset with unit 'd', referenced to a TimeFrame
specified as:
timeScale = TDB
refPosition = BARYCENTER
timeOrigin = (ISOTIME) 2010-01-01T00:00:00
[since it is barycentric, it also needs a reference direction and a solar
system ephemeris]

Chandra uses a TimeStamp of the kind TimeOffset with unit 's', referenced
to a TimeFrame specified as:
timeScale = TT
refPosition = TOPOCENTER
timeOrigin = (MJD) 50814.0

"Ordinary" date strings (whatever that means) appear to be TimeStamps of
the kind ISOTime,
but still need to be referenced to a TimeFrame containing a timeScale and a
refPosition.

You will find all this also described in the Time 101 email I sent around
last year (or so).

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------


On Thu, Apr 12, 2018 at 1:52 PM, CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

> 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/6a190a05/attachment.html>