Time stamp in EpochPosition

[lmichel]

Problem

There are 2 issues with EpochPosition.epoch, which is currently typed as a Coords:Epoch primitive type (B/J<year>)

1. (raised by @gilleslandais ) Mapping native data on this field is difficult because the epoch in column can be MJD/ISO/year/....
   If the EpochPosition.epoch attribute refers to one of these serializations, the model will miss the serialization mode.
2. The B/J prefix can make the mapped epoch conflicting with the time coordinate system attached to the EpochPosition.

Solution

To solve these 2 issues, EpochPositio.Epoch can be typed as a coords:TimeInstant (see standard P 18) which is an abstract type with 3 subtypes currently supported: JD, MJD and ISO.
In addition to this, Mango should extend coords:TimeInstant with 2 types: Years and Seconds

Proposed actions

1. Duplicate coords:TimeInstant in Mango to avoid mixing components of different models in one Mango class (see Error types and relation to Measurement model Uncertainty #60)
2. Extend it with 2 ivoa:real subtypes: Year and Seconds
3. Set EpochPosition.epoch as a mango:TimeInstant

[mcdittmar]

My thoughts:

re: Problem

• There is no counterpart to the EpochPosition.epoch in the Measurements model.. it was removed until a proper workflow would be able to exercise it (like this!).
• The coords:Epoch is currently used only for the SpaceFrame.equinox, where the 'B1950" type format most often comes into play. There was some discussion (Francois?) about adding it to the TimeInstant types. I think that didn't happen because I felt it needed more justification.
• So, I don't see a problem with NOT using the coords:Epoch type for the mango:EpochPosition.epoch if it isn't a good fit in the workflow.

re: Solution(s)

• since coords:Epoch is a primitive type, Mango could enhance the allowed 'representations' it should expect. Given that the values are apparently well represented by the coords:TimeInstant, this doesn't seem like a good solution.
• IF the "J2000.0" form is to be allowed/expected at the mango:EpochPosition.epoch, then I do think that is added justification into bringing the Epoch type into the TimeInstant grouping. But your point about "B1950" possibly conflicting with the associated frame could be problematic.
• Your proposal for extend coords:TimeInstant with 2 types: Years and Seconds
  • I don't quite follow these.. can you give an example? They sound like the "coords:TimeOffset" type, "Seconds since T0" or "Years since T0"... both of which would be handled by that type.
  • could you're EpochPosition.epoch be satisfied by the 'coords:TimeStamp' ?

[lmichel]

re: Problem

I note an agreement for not using coords:Epoch anymore.

[lmichel]

since coords:Epoch is a primitive type, Mango could enhance the allowed 'representations' it should expect. Given that the values are apparently well represented by the coords:TimeInstant, this doesn't seem like a good solution.

The implementation of primitive type representations, especially with Mivot is not clear for me. I get it as a complex type, giving the representation (e.g. ISO), wrapping a primitive value (an ISO string).

[lmichel]

Your proposal for extend coords:TimeInstant with 2 types: Years and Seconds

The epoch is often given as a year (e.g. 2015.5) without any frame reference. This is not a time offset, but an absolute date. Of course, it can be argued that any absolute coordinate is an offset from the origin of the system, but if you say 2015.5, everyone understands it as 6 months after the year 2015 in the christian calendar, not as a 2015.5 years offset.

For the seconds, I've in mind the Unix time which is the number of seconds from 1970-01-01 (https://www.unixtimestamp.com/). I admit that I've no concrete astronomical example for this, and that his representation can be discarded.

[lmichel]

The current proposal looks like this (Seconds should be pushed out)

• In blue: the data types duplicated from CoordsDM with a major difference which is that mango:TimeInstant does not explicitly refer to a TimeSys, but implicitly to this of the EpochPositon object.
• In yellow the the representations added by Mango.

All of the epoch package data types belong to Mango: no cross-model import.