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?
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.
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.