TIMESYS and integer-nanoseconds times

[Pierre Fernique]

Concerning Aladin, it should process similarly to Topcat. If the unit of 
the concerned column is not 'd', an adequate conversion is applied.
Notice that Aladin time functions is based internally on a 'double' 
coding. The 'ns' precision will be probably not fully kept (to be 
verified).

Pierre

Le 29/08/2024 à 10:21, Mark Taylor via apps a écrit :
> 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/