Astronomical timescales

Question

Astronomical timescales

helgee opened this issue 8 years ago · 5 comments

Nice work! 👍

Would it make sense to implement the zoo of astronomical timescales in this package or should they rather live someplace else, e.g. AstronomicalTimescales.jl?

ToDo

Answer 1 · 2016-11-01T10:15:31.000Z

Thanks @helgee.

I was thinking that we should have those periods, since they are used for scientific time records. On the other hand, we currently have some use of dates w.r.t. the "epoch" of a clock, so it would sometimes be nice if one year after the epoch Date it was always the same day of the same month...

Would astroyear and so-on be obnoxious? Can we ignore calendars completely with respect to Duration, and stick to constant, scientific definitions? What the heck is a month going to be (if we have it at all?)?

Or maybe we have year being the astronomical one and have a special type for calendar periods that change to match the epoch. Maybe the Base.Dates module is sufficient for date-based timescales, and we can only do those calculations on the Clock's epoch...

Lots of maybe's. Opinions?

Answer 2 · 2016-11-01T10:28:43.000Z

I'm thinking that everything calendar-related is sufficiently covered by Base.Dates. Due to all of the problems you mention astronomers usually count a real number of days since a given epoch, e.g. for the epoch J2000 day 0 is 2000-01-01T12:00:00.000.

In any case I will try to implement that stuff and prepare a pull request.

Answer 3 · 2016-11-01T12:46:46.000Z

Hi Helge, I think it would be great to have all the machinery to implement astronomical time scales properly in Chrono.jl.

It might make sense to put those time scales in a different package in the longer term, but I'd be happy to have them here while we work things out - this package is in early development still. (One thing which still bothers me about the current Chrono.jl is the central role taken by dates. I don't like dates; different people mean different things by them, and I think they end up being pretty confusing when you're trying to do accurate time keeping! I'd prefer to keep them at arm's length, and only convert when necessary for human-readable output.)

One of the interesting issues with astronomical time scales is that switching between time systems technically requires an offset and a scaling due to relativistic effects. This isn't something which we've dealt with yet.

Answer 4 · 2016-11-02T11:17:53.000Z

How about counting full days (with one day always having 86400 seconds) since an epoch and then counting nanoseconds from the start of that day?

Answer 5 · 2016-11-02T12:45:22.000Z

I'd like a fully flexible internal format: if someone wants to use an Int128 for counting in units of 2/3 femtoseconds since epoch, that should be totally ok by Chrono.jl :-) In fact, Andy has already achieved this very nicely in Duration:

julia> Duration{2//3 * 1//1000_000_000_000_000, Int128}(10)
10 periods of 1//1500000000000000 seconds

My unease is more that dates are embedded in the parameterization of clocks (UTCDate and GPSWeek), and that these dates encourage people to think of an epoch as measured with respect to some other given time system. But this may or may not be true; the shift between one clock and another just may not be known if it's not measured. If it is measured, it will inevitably only be known to within some statistical distribution.

Of course, I recognize that people do, in fact, commonly have a clock which was tied to UTC at epoch, to a good approximation. So we should provide a nice way to deal with this; I'm just not sure we have quite the right thing yet.

@andyferris regarding year, month, etc, I think we should define these in Chrono as the average year and average month, in SI seconds. This way it's easy to do quick order of magnitude calculations in human-friendly units, but we avoid all the imprecision and ambiguity of calendar calculations. As a scientific library, there should be no expectation that adding a Chrono.Month to some epoch will, when converted back to a UTC date give the "same numbered day in the next month". This should only be true on average!