Exemples de systèmes temporels définis pour des missions :

Dans la table, METAtimeSyst, on a défini (en plus de Gaia et Unknown) :

XMM

Avec un scale_name = TT, un frame_name = Unknown (probablement GEOCENTER mais Ada doit vérifier) et donc une erreur systématique de 100s - pas d'offset.

Pour l'instant, il n'y a pas de catalogue associé, on ne voit donc pas le système dans la table générale METAtime - ce ne sera plus le cas lorsque le système XMM sera rattaché au catalogue IX/50 -- ou au catalogue J/ApJ/851/L27 plus bas -- (on le verra alors dans METAtime).

Ada a vérifié avec les archives de la mission EXTraS, on a scale_name = TDB (numero 13 dans METAtimeScaleRef) et c'est bien GEOCENTER pour le frame_name (= ID 2 dans METAtimeFrameRef)

SDSS

Avec un scale_name = TAI et un frame_name = TOPOCENTER, pas d'offset, pas de relation (quasiment toutes les colonnes sont liées à la date d'observation) et pour l'instant time_representation = CUSTOMIZED

Pour TOPOCENTER (dans ce cas = Apache Point Observatory), on n'a pas besoin de préciser les latitudes/longitudes des observatoires.
Note : scale_frame et frame_name étant définis, on n'a pas de time_systematic_err dans ce cas.

N.B. : Dans le catalogue SDSS (V/147), on a seulement une "ObsDate" (col. 18), date moyenne en decimal years qui a l'air d'être toujours plus ou moins la même... Ada doit voit avec Thomas B. s'il n'y a pas mieux à récupérer dans les autres tables de CasJobs pour le Sloan pour la DR14 (dont la publi est sortie récemment). Normalement, on devrait avoir MJD et donc un time_representation = MJD.

PanSTARRS

Avec scale_name et frame_name pour l'instant = UNKNOWN donc un time_systematic_err de 1000s et un time_representation = MJD pour la colonne "epochMean" (col. 10) donc pas d'offset.

N.B. : Pierre voit avec Bertrand G. si on peut faire mieux que UNKNOWN...

Bertrand n'a pas mieux mais Ada pense pouvoir retrouver les infos en cherchant un peu.

Swift

frame_name = BARYCENTER, scale_name = TDB (http://swift.gsfc.nasa.gov/analysis/suppl_uguide/time_guide.html)

Heasarc

Pour les missions RXTE, Swift, Chandra/AXAF, NuSTAR and NICER.
Voir Pierre pour la description.
Voir la définition du barycorr http://heasarc.gsfc.nasa.gov/lheasoft/ftools/fhelp/barycorr.html - corrections qui sont nécessaires pour les études de variabilité des sources et qui tiennent compte de la variation de temps des différentes horloges mais aussi des directions dans lesquelles une source est observée et de la localisation des observatoires.

Exemples de métadonnées temporelles associées à des catalogues :

J/ApJ/851/L27 (LCs of 3XMMJ004232.1+411314):

Pour la colonne "Date" qui est la seule à nous intéresser, il faut associer un time_representation = ISO et les observations venant de XMM, on peut lui attribuer un time_system = XMM (que l'on a déjà défini plus haut avec scale_name, frame_name et offsets).

Une commande à rajouter dans le .status pourrait être du type : \viztime{J/ApJ/851/L27}{Date}{time_rep=ISO time_syst=XMM}

Remarques :

• La colonne "Exp" ne nous intéresse pas car elle varie. Le time_uncertainty peut être défini mais avec une valeur constante pour toutes les observations.
• La colonne "Deltat" ne nous intéresse pas car elle concerne une variation de temps de la mesure et pas les observations.
• Pas de valeur à relier à la date d'observation dans ce cas.
• Les métadonnées n'apparaissent pas dans METAtime pour ce catalogue car il n'est pas encore en ligne (donc n'a pas encore de catid, tabid, colid, etc.)

Seule la table 1 nous intéresse : ce sont les mêmes observations qui sont reprises dans les autres tables.
Il y a une date ISO start et end et un MJD : on se contente du MJD (start => l'ucd1+ time.start permet de préciser qu'il s'agit le temps de début). time_representation est donc MJD.
La colonne "Exp" varie trop pour pouvoir être indexée dans le time_uncertain.
time_syst_id = celui correspondant à Swift que l'on a créé plus haut.
Pas d'offset.
Comme il n'y a qu'une seule colonne de temps, il n'y a pas besoin de définir les relations avec les colonnes liées au temps. On se sert de ces relations uniquement s'il y a plusieurs colonnes de temps (voir exemple de Gaia) pour définir les colonnes associées à chaque temps respectif.

J/ApJ/849/36 : La table 3 (flare parameters : plusieurs St-BKJD et End-BKJD pour les KICs de la Table 1) nous intéresse. Dans la table 1, la colonne "Date" (d) semble être une moyenne des temps d'observation de T3, elle n'est donc pas intéressante pour un suivi "time domain".
En T3 : St-BKJD est la colonne de temps à indexer.
frame_name = Barycenter;
time_representation = JD;
time_offset = 2454833
ucd1+ = time.epoch;time.start
Une seule colonne de temps donc pas de relation à définir.

N.B. : Système Kepler (TDB + GEOCENTER?) - On peut voir ici : http://cdsarc.u-strasbg.fr/cgi-bin/getUCD?tab=col&words=Kepler+date que la "Kepler Julian Date" n'est pas très courante dans VizieR.

J/ApJ/848/L16 (LCs pour contrepartie de GW170817):

time_representation = MJD;
Pas d'offset et pas de relation à définir
scale_name = UT -- donné en Description du ReadMe;
Il y a un temps d'intégration ("30s exposures"), dans cette même section Description, qui pourrait rentrer en time_uncertain mais il n'est donné que pour les bandes i et z alors qu'il y a d'autres filtres dans la table donc ce champs restera vide.
frame_name est UNKNOWN, il y aura donc un time_systematic_err de 1000

-- EmmanuellePerret - 2018-07-16