OE002 Ambiguous datestamps in filenames

    Ambiguous datestamps in filenames #

    Problem ID Manufacturer Affected Firmware Affected Hardware Status
    OE002 Wildlife Acoustics, Open Acoustics Devices multiple multiple minor problem

    Almost all Ecoacoustics software depends on having date stamps in the filenames of audio recordings.

    Without them we don’t really know when a recording occurred and it is difficult to use that data for science and impossible to accurately archive it.

    Most sensors do record such datestamps, but those datestamps are recorded in local time only. This makes sense as most sensors have only one time source and no external way of verifying what the true time is.

    If one is working in only one timezone and field personnel are meticulous in setting the sensor’s clock to local time when the sensors are deployed then this is not really an issue.

    However, if:

    • You have audio collections from more than one UTC offset
      • e.g. Daylight Savings Time is in effect for the area
    • You have audio collections from more than one timezone
      • e.g. You deploy sensors in one national park across state-line boundaries and those states are using a different timezone
    • You are a repository or an archive for audio recordings: An archive of audio with ambiguous datestamps is essentially useless.

    then, you’ll need to ensure the datestamps on your audio files are unambiguous.

    The terms ambiguous and unambiguous refer to the fact that a datestamp that indicates it’s relation to UTC (it’s offset) is unambiguous: i.e. we know exactly what real date and time the datestamp is referring to.

    Ambiguous datestamps have no relation to UTC. Thus for any datestamp it could occur potentially in any of the ~37 timezones that exist in the world.

    Examples:

    • Ambiguous
      • 20220506_230000.wav - seen on most Wildlife Acoustics sensors
        • Newer Audio Moth firmwares also emit dates like this. While they are technical unambiguous if you know the files are produced from an AudioMoth, the datestamp itself does not contain the information.
    • Unambiguous
      • 20220331T094900-0300_Rec.flac - seen on newer Frontier Labs sensors. The -0300 section indicates that the datestamp was 3 hours behind UTC
      • 20191026T000000+1000_REC.flac - seen on newer Frontier Labs sensors. The +1000 section indicates that the datestamp was 10 hours ahead of UTC
      • 5B07C752.WAV - seen on older Audio Moth firmwares. These dates, while unreadable to a human, are a date that is always recorded in UTC.

    Status #

    This problem is more or less endemic on any sensor that does not have a GPS unit or an automatic method of synchronizing it’s internal clock.

    Status with vendor #

    Most vendors do not consider this an issue.

    Frontier Labs now encode UTC offset in their datestamps.

    Effects of the problem on common tools #

    Acoustic Workbench (Ecosounds, A2O) #

    Will not accept files without additional information - the UTC offset of the local time when the sensor’s clock was calibrated.

    Analysis Programs #

    Will process files, but some analyses/fields will not be available. Specifying the UTC offset via a command line option is allowed.

    ffmpeg/ffprobe #

    No effect.

    EMU #

    Can add UTC offsets to filename datestamps. See Emu: Renaming