search

IAU-ADES / ADES-Master

ADES implementation based on a master XML file
26 stars 7 forks source link

obsTime conversion in mpc80coltoxml #59

Closed stevechesley closed 2 months ago

stevechesley commented 3 months ago

Compared to mpc80coltoxml.py, the MPC is writing an extra digit for the seconds in obsTime when converting from obs80.

The ADES tools should match what the MPC is doing, which can be summarized as having 3 less digits after the decimal point for obsTime seconds than were found for the decimal day.

So 2024-04-18.215907 will go to 2024-04-18T05:10:54.365Z, etc. But integer seconds is the lowest precision allowed in ADES. So 2024-04-18.25 will go to 2024-04-18T06:00:00Z.

@federicaspoto please make sure I've got this right...

Bill-Gray commented 3 months ago

Is that really the way we're supposed to do it? Your example to 10^-6 days = 0.0864 seconds requires the time to be given to 0.01 second precision to ensure round-tripping (80-column to ADES back to 80-column); the millisecond precision doesn't really harm things, but I don't see how it helps?

I've been converting 10^-5 day punch-card times to have 0.1-second precision and 10^-6-day ones to 0.01-second precision.

stevechesley commented 3 months ago

@Bill-Gray What you describe is the same as what the ADES converter (mpc80coltoxml) has been doing. The issue is that the MPC database has one digit more than is strictly needed, but this does no harm, and there are benefits to consistency between MPC and ADES tools. The judgement is that adapting the ADES tools to the MPC approach is preferable to them changing their conversion given that their database is already fully populated.

You'll recall there was an earlier discussion that the MPC did not have enough digits in the angles after converting from obs80, but they did fix that one. This is different because they have one digit too many rather than one too few.

federicaspoto commented 3 months ago

So 2024-04-18.215907 will go to 2024-04-18T05:10:54.365Z, etc. But integer seconds is the lowest precision allowed in ADES. So 2024-04-18.25 will go to 2024-04-18T06:00:00Z.

@stevechesley you forgot a zero at the end, but other than that, everything is correct: 2024-04-18.25 go to 2024-04-18T06:00:00.000Z

federicaspoto commented 3 months ago

@Bill-Gray that's exactly as Steve described.

Bill-Gray commented 3 months ago

@stevechesley @federicaspoto - thanks for the explanation. The extra digits don't really harm anything, and round-trip conversion should use precTime anyway. So... carry on; I have no reasonable grounds for objection.

stevechesley commented 3 months ago

OK, final answer: obs80 -> ADES always round obsTime to nearest millisecond.

@stevenstetzler go ahead with this when able.