jac5796
commented
2 weeks ago Yes, the times should be adjusted for leap seconds.
JJohn A. Collins Dept. of Geology and Geophysics, MS 24 Woods Hole Oceanographic Institution 360 Woods Hole Road Woods Hole, MA 02543
e-mail: @.*** voice: +1-508-289-2733
On Jun 13, 2024, at 13:03, Wayne Crawford @.***> wrote:
OBS dataloggers do not (to my knowledge) account for leap seconds, so the data (and possibly the clock sync) needs to be corrected for this.
In the recommended clock correction section, we specify that the "reference" (GNSS, in general) and instrument times should be compared for the beginning and end of the experiment, and maybe at intermediate times if the drift is measureably non-linear.
My question is: should the instrument time provided be "adjusted" for any leap-seconds?
FOR:
Drift correction calculations do not need to account for leap seconds: if users DON'T do this, then the proposed msmod drift correction will skew everything If intermediate clock comparisons are provided, it is much easier to figure them out if the leap-second has already been eliminated from the equation. AGAINST:
the term "instrument time" implies the time indicated by the instrument, not a corrected time Correcting the leapsecond offset programmatically avoids operator error. I'm not sure how this would work for time cross-correlations or John's CSAC-correction: would these be more logical in one case than in the other?
Ideally, the instrument times would be the true ones and the leap second correction (which would be run before correcting clock drift) would somehow modify the instrument times in the clock comparison file, maybe adding a "time zone" like +00:01 to the given time to indicate that the leap second was corrected?
— Reply to this email directly, view it on GitHub https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFDSN%2FOBS-standards%2Fissues%2F14&data=05%7C02%7Cjcollins%40whoi.edu%7C15e9251aaa4741773a3708dc8bcabfc4%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C638538950157158682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3WBPY6%2BWIySTTApWHJzndvRif5IZzgvOpTFOAWG6s%2FI%3D&reserved=0, or unsubscribe https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACEP43Z3MEKIJVRTF342VLDZHHGGDAVCNFSM6AAAAABJIZT2DWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2TCNRUGUYDAMY&data=05%7C02%7Cjcollins%40whoi.edu%7C15e9251aaa4741773a3708dc8bcabfc4%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C638538950157172862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=w6ChYLzltQjMJssNEW7hJ0esBdVNIlghlrwmygFxR3g%3D&reserved=0. You are receiving this because you are subscribed to this thread.
OBS dataloggers do not (to my knowledge) account for leap seconds, so the data (and possibly the clock sync) needs to be corrected for this.
In the recommended clock correction section, we specify that the "reference" (GNSS, in general) and instrument times should be compared for the beginning and end of the experiment, and maybe at intermediate times if the drift is measureably non-linear.
My question is: should the instrument time provided be "adjusted" for any leap-seconds?
FOR:
AGAINST:
I'm not sure how this would work for time cross-correlations or John's CSAC-correction: would these be more logical in one case than in the other?
Ideally, the instrument times would be the true ones and the leap second correction (which would be run before correcting clock drift) would somehow modify the instrument times in the clock comparison file, maybe adding a "time zone" like +00:01 to the given time to indicate that the leap second was corrected?