Dear friends,
We are planning some samplings this autumn that will involve sampling across the daylight saving period (28th of November at 2:00 am this particular year), and when testing the performance of the timer on that particular period (by modifying time and date on a Windows 7 machine), we've found that before the GTM official change the devices work fine and record within the selected period, but once the official time change has taken place (moved from GMT+2 to GMt+1), the recording start one hour before due time. The issue seems to be consistent across devices.
Any idea of what could be happening?
Many thanks!
We're testing the next version of the firmware and configuration app now and have added support for local time zones. It won't do the transition between summer time, but enables you to enter recording periods in local time, see the time on the device in local time, and generate named files and timestamps on the SD card in local time (including the comment in the header which can be in local time with the corresponding time zone information). You can toggle between UTC and local time from the configuration app. This should make it easier to manage time zones.
Ah yes. Because the AudioMoth created the file on the SD card the file created time stamp is in UTC as well. Normally these are in local time when you create a file on your computer.
Thanks for the quick replies, and sorry for the silly question. David Lee's answer point to I was doing wrong: instead of getting the recording time from the filename or the metadata (we normally run a script to do so) I was quick reading the dates from the folder explorer in my computer, which shows GMT dates and applies the time shift accordingly.
Thanks!
The new firmware, which will probably be out this week or next, will also write the filenames with full timestamps - 20180923_104030.WAV - to make it a bit easier to see when the files were created.
The good news is that birds and bats don't know about time zone changes either. So what AudioMoth does is probably what you want to do anyway.
Hi Xavier,
I'm not sure that I follow the description but it seems that you are expecting AudioMoth to adjust the start time to accommodate the change in daylight saving time?
AudioMoth knows nothing about time zones or changes between summer time and winter time. When you configure the device the time is set to the current time in UTC (the same as GMT) and the start and stop times are all set to their value in UTC. The device will stick to these times no matter what the local political time changes are.
So, if you are on GMT+2 when you configure the device and you want to start recording at 22:00 local time, then you need to set the start time to 20:00 UTC. If local time moves to GMT+1 during the recording period, the AudioMoth will still start recording at 20:00 UTC, but that is now 21:00 local time.
Is that the time shift that you are observing?
Alex
Hi Xavier
I've just tried the same experiment setting recording periods before and after changing the date and time on my Windows 7 PC from BST (UTC+1) to GMT (UTC). In both cases recording started and finished at exactly the correct programmed times and the filenames displayed the correct UNIX epochs.
How are you determining the recording times - from direct observation of the LED state or examination of the filenames?
Whilst the actual recording periods were obviously correct, initially I thought that my file times replicated your observations (with "GMT" times behind by 1 hour), until I remembered that my conversion script returns local time (ie uses jscript <DATE>.gethours()) and so was correcting for the 1hour time change between the two sets of recordings, based on the recorded date. When I changed the script to return all times as UTC (<DATE>.getUTChours()) then all times were correct.
Is there any chance that you may have made the same simple mistake that I did?