Votable TIMESYS vs Coords:TimeFrame

[BaptisteCecconi]

Following a recent discussion in Semantics, I'm trying to understand how we can use Coords to describe something as simple as a Votable TIMESYS description.

According to the current VOTable 1.5 WD, TIMESYS is composed of 4 attributes:

• ID, used for referencing the TIMESYS element in the document.
• timeorigin, the time origin of the time coordinate
• timescale, the time scale used (from http://www.ivoa.net/rdf/timescale)
• refposition, the reference position (from http://www.ivoa.net/rdf/refposition)

If I try to implement this using a coords:TimeFrame, I can include:

• a refPosition,
• a timescale
• a refDirection.

No "time origin" here.

Looking at the Coords specification, it seems that we need to use a TimeOffset data type if I want to define a time origin, so the information is split in different places than on Votable TIMESYS.

However, if I look at the same document, and check the definition of the MJD data type. It is defined as a coords:TimeInstant, not a coords:TimeOffset. The text description says that it is a time in days measured from 2400000.5.

If I were to redefine MJD (see here for a list of various JD reference times used in other contexts), I would need to define it as a coords:TimeOffset, right?

Furthermore, is there any numerical time representation that is not a time offset? For instance: "unix time" of the number of seconds since January 1st, 1970 00:00:00 (UTC).

There may be a subtle reason why Coords:TimeFrame is defined in a different way than Votable:TIMESYS. However the way MJD is defined seems inconsistent. And the fact that the time origin of MJD is just a comment in the text description is really a bad solution.

[mcdittmar]

@BaptisteCecconi , sorry for the delayed response..

Following a recent discussion in Semantics, I'm trying to understand how we can use Coords to describe something as simple as a Votable TIMESYS description.

According to the current VOTable 1.5 WD, TIMESYS is composed of 4 attributes:

• ID, used for referencing the TIMESYS element in the document.
• timeorigin, the time origin of the time coordinate
• timescale, the time scale used (from http://www.ivoa.net/rdf/timescale)
• refposition, the reference position (from http://www.ivoa.net/rdf/refposition)

If I try to implement this using a coords:TimeFrame, I can include:

• a refPosition,
• a timescale
• a refDirection.

No "time origin" here.

Looking at the Coords specification, it seems that we need to use a TimeOffset data type if I want to define a time origin, so the information is split in different places than on Votable TIMESYS.

I've considered TIMESYS and COOSYS as 'standard serializations' for the Coords model content, given certain constraints.
Below are the comments I posted to the RFC page for VOTable-1.4 describing the relation of Coords to TIMESYS.

TIMESYS

• refposition => coords:TimeFrame.refPosition with value from StdRefLocation vocabulary at (https://www.ivoa.net/rdf/refposition). same
• timescale => coords:TimeFrame.timescale with value from vocabulary at (https://www.ivoa.net/rdf/timescale). same
• timeorigin => coords:TimeOffset.time0. This is not part of the TimeFrame in the coords model, but rather on the Time coordinate type which requires it. The descriptive restrictions in TIMESYS regarding when it MUST/MUST_NOT exist are compatible with the various TimeStamp types in the coords model. Note: that the type is restricted to JD here, which is more restrictive than the model allows, but appropriate for this usage.
  In short; both elements are compatible with the coords model, except for the omission of COOSYS.refposition which would be needed to generate a valid SpaceFrame instance.

So yes, the timeorigin element of TIMESYS provides the origin of a TimeOffset instance, the thinking being that all of them will have the same origin, so consolidate it into the TIMESYS object.

However, if I look at the same document, and check the definition of the MJD data type. It is defined as a coords:TimeInstant, not a coords:TimeOffset. The text description says that it is a time in days measured from 2400000.5.

If I were to redefine MJD (see here for a list of various JD reference times used in other contexts), I would need to define it as a coords:TimeOffset, right?

The Coords model has no use cases where it needs any other variants to MJD. If this was requested, there would be a discussion about whether to make additional "TimeInstance" types or a more generic solution. I think that what we have here is consistent with the AstroPy implementation (timeMJD = "This represents the number of days since midnight on November 17, 1858. "

Furthermore, is there any numerical time representation that is not a time offset? For instance: "unix time" of the number of seconds since January 1st, 1970 00:00:00 (UTC).

The current set helped resolve the scenario: " here is a column with decimal value.. interpret this as a MJD rather than JD". So, if this is another flavor of that scenario, then I'd probably have it supported as another TimeInstant. There was some discussion about whether these were needed, or if it all falls under the umbrella of what the ivoa:datetime datatype is supposed to handle. But.. I really felt there was a need for the user to specifically state how to interpret the value.

There may be a subtle reason why Coords:TimeFrame is defined in a different way than Votable:TIMESYS. However the way MJD is defined seems inconsistent. And the fact that the time origin of MJD is just a comment in the text description is really a bad solution.

TIMESYS is a serialization of the TimeFrame model given certain usage constraints. It is not a model itself.