[coords] Question - Time domain coordinates and frames

[CresitelloDittmar, Mark]

Markus,
Thanks for the new vocabulary word first thing in the morning!

On Fri, Apr 13, 2018 at 4:39 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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?
>
>
Mostly I'm coming from what I've seen in the data products I've worked with.
For what I've seen, the offset has typically been given in MJD.  So there
seems to be a need for some flexibility here.



>
> 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):
>
> Typically I would agree.   IF the value in MJD, JD, ISO, etc are different
representations of the same TimeInstant (which is the main question here,
which I haven't seen a yes|no answer about).. then it is not really on the
model to distinguish between them.. a TimeInstant with value:datetime[1] is
enough.

However, there is the practical side where a client has to interpret actual
data.  Since JD and MJD are both real numbers, there is ambiguity about how
to interpret any given real number.  From your example below, one could
infer that the value is MJD because the timeOrigin is the JD-MJD offset.
If that were not there, the client would misinterpret the value as a JD.
What are the odds a provider would forget/neglect to add this static
timeorigin value into the frame because their dateObs is in MJD.
This is why I would like to have something in the model which gives
providers a way of annotating specifically.. this COL has times expressed
in MJD.


>       <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20180413/71ea9fd3/attachment.html>