[coords] Question - Time domain coordinates and frames

[Markus Demleitner]

Hi DM,

On Thu, Apr 12, 2018 at 02:49:59PM -0400, Arnold Rots wrote:
[timeOrigin as a TimeFrame; incidentally, I'd like to propose doing
inline replies, as it's much easier to follow the discussion then]
> 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)
> 
[...]
> The timeOrigin should expressed as a TimeStamp (JD, MJD, or ISOTime, but
> NOT TimeOffset),
> referenced to the same TimeFrame.

I'd say that's a bit too apodictical.  What does this complication
buy us over the plain and easily implemented (i.e., less chance of
bugs) specification that timeOffset (or perhaps "epoch") simply is
the number of days between JD's zero point and the chosen frame's
zero point in BARYCENTER?  Is there any sane time scale in which that
wouldn't be good enough?  If there is, couldn't we just declare
non-support of this in the interest of getting something workable
out?



While we're on the topic of time representations: I still argue the
serialisation of times is not a matter of the data model.  Whether
something is something in days, or seconds (unix timestamps!) or the
whacky civil calendar is up to the serialisation and needs to be
handled there.  Hence, an MJD in VOTable would simply be specified
using (in classic STC-in-VOTable notation):

  
      <GROUP utype="stc:CatalogEntryLocation">
        <PARAM arraysize="*" datatype="char" name="ReferencePosition" 
          utype="stc:AstroCoordSystem.TimeFrame.ReferencePosition" 
          value="BARYCENTER"/>
        <PARAM arraysize="*" datatype="char" name="TimeScale" 
          utype="stc:AstroCoordSystem.TimeFrame.TimeScale" value="TDB"/>
        <PARAM datatype="double precision" name="TimeOffset" 
          utype="stc:AstroCoordSystem.TimeFrame.timeOrigin" 
          value="2400000.5"/>
        <FIELDref ref="COL" utype="stc:AstroCoords.Time.TimeInstant"/>
        [...]
      </GROUP>

  <column id="COL" name="dateObs" datatype="double precision" unit="d"/>

Of course, this neat plan breaks down here and there; in this
particular case I'd strongly suggest we include some prose of
the type 

  The use of timeOrigin is undefined for time representations that
  include explicit years (like 2013.143 or 2013-02-23).  This model
  at this point only supports the Christian era and the Gregorian
  Calendar for such representations.

Extensions for other calendar systems might come later, but at this
point it would be, I argue, grossly misleading to be able to change
2013-02-23 to, say, 2012-04-12T12:30:00 using the time frame.

           -- Markus