[TAP] data type for column metadata

Rob Seaman seaman at noao.edu
Tue Mar 24 15:24:36 PDT 2009


Patrick Dowler wrote:

> in ADQL (SQL) that other argument is expressed as a string, eg:
>
> SELECT * FROM someTable WHERE someDate <= '2009-01-01 01:02:03.4'
>
> In terms of TAP I recall that we specify that the format of the  
> constant is
> iso8601 and if we haven't we need to specify exactly which  
> variant(s) are
> allowed.

The command line or GUI will often rely on string valued parameters.   
As with other UI constructs, the format and range should be constrained.

I'm still concerned that notions like "constant == iso 8601" are being  
tossed around.  The key issue here is whether "timestamp" means an  
epoch or rather a calendar date.  In the case of a query like this,  
the epochs will usually enter as a range:

	"give me the data between epoch1 and epoch2"

But dates will tend to represent calendar dates from some observing  
schedule:

	"give me the data from the night of date1"

During the course of date1, the epoch is almost always going to click  
over from one day to the next, whether expressed in local time or UT.   
(The NOAO Science Archive uses a local noon pivot to index into the  
observing calendar.)

Which is to say that an epoch represents a floating point number  
(whether expressed as a string or not, ISO 8601 or not).  But a date  
represents an integer count of days (ditto about strings and ISO).  It  
either is - or is not - a specific date, but an epoch represents an  
instant that is either in the past or the future.  Usage of these two  
time constructs is not interchangeable.  Another way to look at it is  
that an epoch is a point on a number line.  (And STC tells you which  
number line.)  A date is a (half-open) interval.

Just as we should discuss data models at a sufficiently high level to  
avoid getting lost in the intricacies of XML schema - we should  
discuss queries and other task examples in a general enough fashion  
that the peculiarities of SQL (for instance) don't confuse the issues.

Rob



More information about the dal mailing list