TIMESYS and integer-nanoseconds times

[Mark Taylor]

Gregory,

I don't see any problem with this as far as the standards go -
by my reading, VOTable 1.5 is quite consistent with a TIMESYS-referencing
FIELD that uses (a) an integer datatype and (b) a (VOUnit-compatible)
non-day unit attribute.

I can't speak for Astropy or Aladin, but the current TOPCAT release
almost does this right (though it doesn't make very much use of time
information beyond plotting).  It will understand something like:

   <TIMESYS ID="time_frame" refposition="BARYCENTER" timeorigin="2455197.5" timescale="TCB"/>
   ...
   <FIELD name="obs_time" datatype="long" unit="s" ref="time_frame"/>

However it currently only recognises a few time units, not including ns.
This will be fixed in the next release (already done in pre-release at
https://www.star.bristol.ac.uk/mbt/releases/topcat/pre/topcat-full.jar)

Mark

On Thu, 29 Aug 2024, Dubois-Felsmann, Gregory P. via apps wrote:

> Dear colleagues,
> 
> In Rubin we are having another round of a familiar conversation, about how to represent scientifically meaningful time stamps in databases and in tabular data formats such as Parquet.
> 
> The immediate question that's come up in this conversation is whether the current IVOA standards would give us a fully standards-compatible way to represent time stamps in a form like "nanoseconds since the MJD epoch", on the TAI timescale, in a signed 64-bit integral type.
> 
> We can obviously declare a column in a VOTable or a TAP database table as 64-bit-signed-integer, and give it units of nanoseconds.  The question is whether the way the standards are written would permit using TIMESYS to define the desired time origin and time scale, or whether the use of TIMESYS is incompatible with the use of units of "ns".
> 
> Demleitner, Nebot, et al. (2018) (https://www.ivoa.net/documents/Notes/TimeSys/20181212/NOTE-timesysnote-1.1-20181212.html) seems to say explicitly that this should work: 
> 
> "As long as these standards are followed, no interoperability problems are forseen regardless of whether times are given in years, days, seconds or any derivation of them."
> 
> VOTable 1.5 is less explicit about this.
> 
> I'm curious about whether there's prior art in the community for doing this for MJD-origin times with units that are not days, and whether it's known whether commonly used clients (Astropy, Aladin, etc.) would process them correctly.
> 
> Many thanks,
> 
> Gregory
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/