Skip to content

[clocks] Update Sardinia Radio Telescope clock corrections#41

Open
cuantar wants to merge 1 commit intoipta:mainfrom
kitz0rsoft:upstreaming/main/update_srt_corrections_file
Open

[clocks] Update Sardinia Radio Telescope clock corrections#41
cuantar wants to merge 1 commit intoipta:mainfrom
kitz0rsoft:upstreaming/main/update_srt_corrections_file

Conversation

@cuantar
Copy link
Copy Markdown
Collaborator

@cuantar cuantar commented Mar 24, 2026

This PR updates the clock corrections file for the Sardinia Radio Telescope.

@cuantar cuantar force-pushed the upstreaming/main/update_srt_corrections_file branch from f1f742f to 6c0f535 Compare March 24, 2026 20:39
@cuantar cuantar changed the title [srt] Update Sardinia Radio Telescope clock corrections [clocks] Update Sardinia Radio Telescope clock corrections Mar 24, 2026
@cuantar
Copy link
Copy Markdown
Collaborator Author

cuantar commented Mar 24, 2026

@dlakaplan Here are updated clock corrections for SRT; have I performed all required steps in the procedure for merging them? I can't tag you as a reviewer, and I think we should fix that. Will investigate.

@dlakaplan
Copy link
Copy Markdown
Contributor

Hi, @cuantar Can you explain where you got this from? It looks like the standard plan for SRT is to pull the file from tempo2. So will this work in the future?

@cuantar
Copy link
Copy Markdown
Collaborator Author

cuantar commented Apr 9, 2026

@dlakaplan Joris sent me this file. It came to him via the staff member at SRT who is responsible for the clock files. Pulling the file from tempo2 should work, but has no guarantee to be up-to-date; our impression is that the same person maintains the clock file for tempo2, but only provides updates when asked. There seems to be no automated system that updates the clock files in either repository.

@dlakaplan
Copy link
Copy Markdown
Contributor

So are you suggesting that we also should alter the setup for SRT so it no longer pulls from Tempo2?

@cuantar
Copy link
Copy Markdown
Collaborator Author

cuantar commented Apr 10, 2026

Well. In the ideal case, we'd have one reliable source of truth for SRT clock corrections, whether that be here, or in the tempo2 repo, or somewhere upstream that both projects pull from. I discussed with Joris and we think that the best way to proceed is: (1) merge this file; and (2) keep pulling updates from tempo2 in the future. Someone will have to ask the staff person at SRT for updates in any case. It would be good to collaborate with the tempo2 maintainers about a common plan to keep both repos up-to-date and synchronized.

Are there any ToAs that would be affected by this file? Maybe it won't matter, for now.

@cuantar
Copy link
Copy Markdown
Collaborator Author

cuantar commented Apr 10, 2026

I remember that there was one other detail that needed to be added before this PR is merged, but can't think of what it was. Do you remember?

@dlakaplan
Copy link
Copy Markdown
Contributor

Well. In the ideal case, we'd have one reliable source of truth for SRT clock corrections, whether that be here, or in the tempo2 repo, or somewhere upstream that both projects pull from. I discussed with Joris and we think that the best way to proceed is: (1) merge this file; and (2) keep pulling updates from tempo2 in the future.

I think that will not work, since future pulls from tempo2 will override this change (or we'll get conflicts that don't resolve).

@cuantar
Copy link
Copy Markdown
Collaborator Author

cuantar commented Apr 10, 2026

Ah, I see, so it really is just a pull with no modification time checking.
Then probably we should close this PR without merging it, since we'll run into trouble starting tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants