search

PAMGuard / PAMGuard

Detection, Classification, and Localisation of marine mammal and other bioacoustic signals
http://www.pamguard.org/
GNU General Public License v3.0
37 stars 15 forks source link

Sound Acquisition time zone issues #113

Open htleblond opened 1 year ago

htleblond commented 1 year ago

My team has occasionally come across an issue where Sound Acquisition seems to automatically interpret SoundTrap audio file dates as being in local time even when UTC is selected in the options dialog, as shown in the first image where the date in the audio file name is 2022-12-01-00:00:00, but that gets converted eight hours forward as if the original was in Canada/Pacific. Apparently some of the SoundTrap data we have was accidentally processed in local time, which is probably the culprit, but I'm not sure where in the code it reads the WAV file's metadata for a time zone (I'm assuming I'm just missing something). However, if I set the time zone to Canada/Pacific, it's now at 4am instead of midnight (second image), which doesn't make any sense anyway.

Any ideas? Holly

image image

BrianSMiller commented 9 months ago

I can confirm this bug is occurring for me too when processing .sud files in Pamguard 2.02.10.

I would be strongly in favor of ensuring that Pamguard API only use UTC for reading and writing data (which is what the time-zone option indicates, even though this appears not to be the case).

htleblond commented 9 months ago

Also, the dates written into binary files are in local time, which caused some issues for my plugin when trying to get data line up correctly. I guess if you're on GMT time, then it makes sense that this may have been glossed over.

macster110 commented 2 months ago

Apologies for the very late reply. This can occur of xml files are not included with SoundTrap decompressed wav files. Can you confirm that this is still na issue in 2.02.13 (just released) and we will get on it if so.

douggillespie commented 1 month ago

This problem is very much on SoundTrap, which uses local time for file names. PAMGuard actually tries to find the xml file that accompanies each wav file and get's the time from there. If the xml file is no longer in the same folder as the wav file, then it can't be found and PAMGuard reverts to trying the file name. you're then in an almighty mess of needing to be sure that the computer doing the analysis is set to the same time zone as the computer that set up the soundtrap. So advice 1: Keep the xml files. advice 2: stop even unpacking the data, and use the new features of PAMGuard which will take data direct from the sud file, getting the correct UTC time out of the file while it's at it.