[coords] Question - Time domain coordinates and frames

[François Bonnarel]

Hi all,

My understanding of this:

      - If Time representation is JD, MJD or ISO we don't need any 
TimeOrigin (the origin is included in the definition)

     - In case of TimeOffset, the TimeOrigin has to be given in some 
representation of time, but with the same TimeScale and Refpostion than 
the Frame it is included i

     - In STC JD, MJD,  TimeOffset are  subclasses of TimeInstant. They 
are not attributes. So I wil slightly rephrase Marku's example this way

       <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="TimeOrigin"
               utype="stc:AstroCoordSystem.TimeFrame.timeOrigin.JD"
               value="2400000.5"/>
           ---> Obviously the name here was not TimeOffset but
    TimeOrigin. TimeOrigin is containing a TimeStamp, here it is in JD.
             <FIELDref ref="COL" utype="stc:AstroCoords.Time.TimeOffset"/>
    ---> TimeInstant (or TimeStamp) will be a of "TimeOffset" Type of
    repressentation in the corresponding column
             [...]
           </GROUP>

       <FIELD id="COL" name="dateObs" datatype="double precision" unit="d"/>
        --->Replacing column by FIELD


Cheers
François
Le 13/04/2018 à 14:50, CresitelloDittmar, Mark a écrit :
> 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 
> <mailto: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/3fb44e78/attachment-0001.html>