DALI 1.1, time annotations

[Mark Taylor]

On Thu, 18 Feb 2016, Markus Demleitner wrote:

> Hi everyone,
> 
> On Wed, Feb 17, 2016 at 04:25:21PM +0000, Mark Taylor wrote:
> > That's fine, but I would also like to be able to mark columns in a
> > VOTable that contain timestamps in other formats, e.g.: MJD, JD,
> > decimal year (maybe others ... Unix milliseconds???).
> > 
> > At the moment there is no way to mark up a VOTable column in such a
> > way that you can tell this is what it contains.
> > Units are some help, as are UCDs which can (when present)
> > distinguish between an epoch and a duration.  But none of these
> > can distinguish between a JD and an MJD, because they can't
> > specify a zero point.
> > 
> > This seems to me like a prime use case for xtypes.  So I would
> > suggest at least the following xtype values:
> > 
> >     xtype="mjd"
> >     xtype="jd"
> >     xtype="decYear" (?)
> > 
> > Perhaps experts from CDS can advise on what forms timestamp
> > columns actually exist in in the wild.
> 
> I have all of them in my database, for starters, and I'd dearly love
> to have some way to mark this stuff up in a way that clients actually
> understand it[1].
> 
> And until DALI 1.1 I'd actually have agreed to using xtype like this.
> But DALI 1.1 defines the "interval" type using xtypes, and given
> that's already in use in SIAv2 (and the SODA draft) it's unlikely
> that we can banish that ghost back into the bottle again even if we
> could reach a consensus that's desirable (you'd have my vote,
> though).
> 
> This means that anything that we may ever want to use as interval
> boundaries cannot be marked up using xtype (unless we made xtype a
> compound -- shudder).  And at least for mjd that is very definitely
> the case (both SIAv2 and SODA already have cases).

Oh boy.  I hadn't spotted that.

I could point out that strictly speaking this doesn't affect DALI 1.1
as written, since the current draft says both (sec 3.3.3):

   "Date and time values must be represented using the convention
    established for FITS" [which uses string literals]

and (sec 3.3.4):

   "Numeric intervals are pairs of floating-point values (float or double)."

so you can't have time intervals (if it's an interval it has to be
numeric, and if it's numeric it can't be a timestamp).
But that doesn't seem like a very satisfactory escape, especially
since I'm complaining about at least one of those restrictions
in a different thread.

To me, xtype="mjd" is more persuasive than xtype="interval".
And DALI 1.1 isn't actually out of the bottle yet - I didn't even
know there was a draft until I saw it referenced in the
SODA WD announced on Christmas eve.  But if xtype="interval"
is fundamentally baked in to the multi-D juggernaut I suppose
I'll have to lump it.

> My take on all this is: We need to stop heaping hacks upon hacks and
> finally do a usable *and used* STC data model including a VOTable
> serialisation for it.  If we had had the courage to go the proper way
> through a parameter data model for interval, we wouldn't be  in
> the fix we're in now.  So, let's not repeat history here.

I'm not sure I wouldn't support hack-upon-hack here (compound xtype?
xtype="mjdinterval"?).  But probably it wouldn't take much pressure
to embarrass me out of it.

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/