Answers.Body: <p>If you are using different sensors, they will require synchronization. Even if your camera uses UTC as time stamp, it must be synchronizes before/after deployment.</p>
  <p>Sot sure how you do it, but if you synchronize all your sensors with PC (i.e. NTP) then use this standard (UTC or even Local). If you can synchronize all devices from GPS clock use GPS time.</p>
  <p>In any case time differences between GPS (location measurements) and UTC/Local should always be part of your experimental documentation</p>
  <p>Edit: due to changed question, I would clarify my answer</p>
  <ul>
  <li>Synchronize All your sensors to the same time service (local, UTC or GPS) before and after the experiment</li>
  <li>Keep log of usage (local, UTC, GPS)</li>
  <li>Keep log of time difference of GPS to UTC.</li>
  </ul>
  <p>IMHO, consistency and completeness in data management is more important than anticipating software difficulties. There are even biological reasons to keep the data management in local time and not in UTC or GPS, but this is not subject to OP.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-28T07:51:13.040Z
Answers.LastActivityDate: 2022-07-30T06:26:30.573Z
Answers.LastEditDate: 2022-07-30T06:26:30.573Z
Answers.UserDisplayName: WMXZ
Body: <p>A while ago we decided to use UTC timestamps for our data management of under water acoustic recordings. UTC time is convenient because you can combine it with drone recordings, photo cameras and even time schedules from AIS and flight tracking etc. However, UTC is not continuous, and not monotonic, there are leap seconds. The last leap second was at end of 2017. While processing a continuous recording from 2017, some software suites run into problems. For example, the splitting into files of 10 min duration, and the timestamp of the first sample in the filename, one file contained only data for 9:59 min, but the timestamps were 10 min apart.
  We use GPS synchronized recorders and we log the UTC time offset that is broadcast about every 15 min by the GPS satellites. So, there is technically no problem with the recording and we can compute the precise timestamp of every sample. But for data management purposes and the processing software, using the UTC time can cause the above mentioned problems. We thought about using the GPS or TAI time, which are continuous and monotonic but this is now off by 18 sec to UTC time which could also cause problems.
  What are the pros and cons for using GPS or UTC timestamps for data management in bioacoustics recordings? How do bioacoustics software suites handle leap seconds?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-07-28T17:47:55.340Z
Comments.Text: Interesting question. It might be helpful to readers to write a title that summarizes the specific problem.
Comments.UserDisplayName: ASimonis
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-07-29T17:49:55.423Z
Comments.Text: "What do you prefer" and "What are your thoughts" are way too opinion-based to be a good fit for the Stack Exchange format. Right now, this question is phrased in a very vague and opinion-based manner; basically, any answer could be equally correct (e.g. "I like UTC timestamps more" or "You should use GPS timestamps"), with no way to determine a best answer. There might be a way to edit this question to be less primarily opinion-based (e.g. "What are the pros and cons of using GPS vs. UTC timestamps for recordings?"); you may want to edit it accordingly.
Comments.UserDisplayName: V2Blast
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-07-29T18:37:59.703Z
Comments.Text: ok, thanks. I reformulated the question
Comments.UserDisplayName: Jörg Rychen
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-07-30T19:36:47.780Z
Comments.Text: I was under the impression that we can have questions that are discussion subjects, ideally with tag 'discussion', and that may not require a "best answer" to be selected.
Comments.UserDisplayName: sm1
Tags: <time-align><archive><synchronization><gps><time-stamps>
Title: How to handle leap seconds? UTC or GPS timestamps for data management?
ThreadText: # How to handle leap seconds? UTC or GPS timestamps for data management?
  
  (Asked by: username_0 on 2022-07-28)
  
  A while ago we decided to use UTC timestamps for our data management of under water acoustic recordings. UTC time is convenient because you can combine it with drone recordings, photo cameras and even time schedules from AIS and flight tracking etc. However, UTC is not continuous, and not monotonic, there are leap seconds. The last leap second was at end of 2017. While processing a continuous recording from 2017, some software suites run into problems. For example, the splitting into files of 10 min duration, and the timestamp of the first sample in the filename, one file contained only data for 9:59 min, but the timestamps were 10 min apart.
  We use GPS synchronized recorders and we log the UTC time offset that is broadcast about every 15 min by the GPS satellites. So, there is technically no problem with the recording and we can compute the precise timestamp of every sample. But for data management purposes and the processing software, using the UTC time can cause the above mentioned problems. We thought about using the GPS or TAI time, which are continuous and monotonic but this is now off by 18 sec to UTC time which could also cause problems.
  What are the pros and cons for using GPS or UTC timestamps for data management in bioacoustics recordings? How do bioacoustics software suites handle leap seconds?
  
  **Tags:** time-align, archive, synchronization, gps, time-stamps
  
  > **Comments:**
  > **username_1**: Interesting question. It might be helpful to readers to write a title that summarizes the specific problem.  
  > **username_2**: "What do you prefer" and "What are your thoughts" are way too opinion-based to be a good fit for the Stack Exchange format. Right now, this question is phrased in a very vague and opinion-based manner; basically, any answer could be equally correct (e.g. "I like UTC timestamps more" or "You should use GPS timestamps"), with no way to determine a best answer. There might be a way to edit this question to be less primarily opinion-based (e.g. "What are the pros and cons of using GPS vs. UTC timestamps for recordings?"); you may want to edit it accordingly.  
  > **username_0**: ok, thanks. I reformulated the question  
  > **username_3**: I was under the impression that we can have questions that are discussion subjects, ideally with tag 'discussion', and that may not require a "best answer" to be selected.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2022-07-28. Score: 4
  
  If you are using different sensors, they will require synchronization. Even if your camera uses UTC as time stamp, it must be synchronizes before/after deployment.
  
  Sot sure how you do it, but if you synchronize all your sensors with PC (i.e. NTP) then use this standard (UTC or even Local). If you can synchronize all devices from GPS clock use GPS time.
  
  In any case time differences between GPS (location measurements) and UTC/Local should always be part of your experimental documentation
  
  Edit: due to changed question, I would clarify my answer
  
  * Synchronize All your sensors to the same time service (local, UTC or GPS) before and after the experiment
  * Keep log of usage (local, UTC, GPS)
  * Keep log of time difference of GPS to UTC.
  
  IMHO, consistency and completeness in data management is more important than anticipating software difficulties. There are even biological reasons to keep the data management in local time and not in UTC or GPS, but this is not subject to OP.
  
  
  ---
  
  