[coords] Question - Time domain coordinates and frames

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Sat Apr 14 02:52:53 CEST 2018


I'd just like to point out that in that diagram, ALL of the coordinates
refer to a TimeFrame... and therefore, have a timescale and refpos
available.
In the examples I included, they all refer to the SAME timeframe, but this
is not required (though perhaps discouraged). However, there is no need for
the MJD to 'ignore' an offset that applies only to the TimeOffset type.

You hit on the difference, and the core of the question which started this
thread.
This arrangement says that the Frame applies to an instant, not to a
relative time.  So each of the coordinate types (JD, MJD, ISO, TimeOffset)
define a particular instant
by providing both the zero point (TimeInstant) + offset from there.

Mark


On Fri, Apr 13, 2018 at 5:27 PM, Arnold Rots <arots at cfa.harvard.edu> wrote:

> No, No, No!
>
> JD, MJD, and ISO-8601 have no meaning if the time scale is not specified
> (nor the reference position, for that matter).
>
> A time stamp, whether it is expressed in JD, MJD or ISOTime, always HAS to
> be referenced to a time scale (any time scale) and a reference position.
> Like:
> JD 1456344.845 (TT; GEOCENTER)
> 2018-04-13T17:26:37 (UTC; TOPOCENTER)
> MJD 56345.345 (TDB; BARYCENTER)
>
> None of these is identified with any specific time scale.
> Though, there is a strong warning that JD and MJD (UTC) are dangerous,
> especially on days that contain leap seconds.
>
>   - Arnold
>
> ------------------------------------------------------------
> -------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 496
> 7701
> 60 Garden Street, MS 67                                      fax:  +1 617
> 495 7356
> Cambridge, MA 02138
> arots at cfa.harvard.edu
> USA
> http://hea-www.harvard.edu/~arots/
> ------------------------------------------------------------
> --------------------------------------------------
>
>
> On Fri, Apr 13, 2018 at 8:42 AM, Paul Harrison <
> paul.harrison at manchester.ac.uk> wrote:
>
>>
>>
>> On 2018-04 -13, at 01:10, Arnold Rots <arots at cfa.harvard.edu> wrote:
>>
>> Since MJD is absolute, the client should ignore the timeOrigin. Actually,
>> it should not even look to see whether there is one.
>>
>> In terms of implementation:
>> The common implementation of time is to keep it as either JD or MJD (my
>> code uses MJD, the JPL ephemeris uses JD), as either two doubles or an
>> integer and a double.
>> JD and MJD times would then need either nothing or the JD-MJD fixed
>> offset in order to be stored; ISOTime requires a little more; but only when
>> a TimeOffset if provided would the code actually look for a timeOrigin
>> value.
>> Or, if that feels more comfortable, you can (arbitrarily) assign a
>> default value for the timeOrigin; can be zero or 10^10 or your favorite
>> prime number.
>>
>>
>> I don’t think that in fact things are as simple as this summary presents,
>> both in theory and certainly in practice. I think that it is incorrect to
>> say that MJD is absolute -  it is tied to the UTC timescale for working out
>> the whole day, but then there is the problem of leap seconds - is the
>> fractional part of the MJD for 12 noon on a day with a leap second 1/2 or
>> 43200/86401? The Astronomical Almanac in fact discusses MJDs in different
>> timescales, where there fractional part of the day is calculated in the
>> timescale indicated - so I get the feeling that in general there is not
>> even a consensus of definition of MJD that means that a given MJD double
>> value is completely unambiguous on days with leap seconds - The real
>> problem is the measuring in units of day - only seconds have unambiguous
>> definition, and then you do want to specify an origin to be sure what is
>> meant.
>>
>> ISOTime is tied to UTC and does have unambiguous representation of time
>> on days with leap seconds, and the textual representation can include any
>> timezone offsets in the representation, so need no origin - and for this
>> reason is probably superior to MJD for representing instants of time in UTC.
>>
>> Paul.
>>
>>
>> Dr. Paul Harrison
>> JBO, Manchester University
>> http://www.manchester.ac.uk/jodrellbank
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20180413/5e52732e/attachment-0001.html>


More information about the dm mailing list