Time transformation

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Fri Apr 3 17:36:24 CEST 2020


On Fri, Apr 3, 2020 at 5:04 AM Laurent MICHEL <
laurent.michel at astro.unistra.fr> wrote:

> Hello,
>
> FITS paper II and III are listed in the draft (page 6) but not FITS
> paper IV (time representation).
> It's a bit odd.
> To me, time transformations are symmetric with e.g. spectral coordinate
> transformations, even if they are less used in FITS files.
>

Interesting side-note.. the Time paper was "Approved by the IAUFWG in June
2014".. just about the time Arnold started the STC2 project.
That may have contributed to why it is not in the current scope.

Le 02/04/2020 à 17:35, David Berry a écrit :
> > On Thu, 2 Apr 2020 at 15:55, CresitelloDittmar, Mark
> > <mdittmar at cfa.harvard.edu> wrote:
> >>
> >>
> >> You mean like  DATE => MJD?  GMT - PST?
> yes I do
>
> >> I think these are in the same level as ENERGY-FREQUENCY-WAVELENGTH,
> which are really standardized transforms which are basically considered
> different forms of the same value.  Which is why they are in the Coords
> model as different 'flavors' of  Time coordinate rather than having a
> single time coordinate and using transforms to convert.
> You need a transform to go from a flavor to another.
> If I want to use TRANSF to model e.g. a ground segment processing, I
> might have a step converting spacecraft time to earth time.
> This is very similar with converting pixels to RA/DEC by using attitude
> data among other things or converting spectrometer channels to kEv.
>

I'll basically echo Arnold's statement.  The conversion from one to the
other is a form of transform I suppose, but not one that you will export to
a serialization.  I don't expect anyone will define a MJD column with a
formal Transform expression from a DATE column.
Instead, applications/implementations will implement a Time type and use
the algorithm for making that conversion under-the-hood.  At the very
least, I'd say we don't need it in this version of the model, and come up
with a use-case where that would be necessary and implement that as a
follow-up project.

I'm happy to add some clarifying text about the depth of transform support
in this model (ie: not having  equatorial-galactic, energy-wavelength,
date-hjd (that's for you Arnold! nice to see you're still watching.) ).

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200403/5e7d656b/attachment.html>


More information about the dm mailing list