gopro/OpenGoPro

Timezone handling HERO12/HTTP API

mijoost opened this issue · 0 comments

Timezone information seems to be handled inconsistently in the camera (Hero12/H23.01.02.20.00). Not sure how much of this relates to the (HTTP-)API.

I live in CET (UTC+1) timezone with currently DST active (so, CEST=UTC+2). In the camera menu I have set timezone=UTC+1 and DST=On.
Took a video starting at 14:41 CEST; MP4 creation_time tag of that video is yyyy-mm-ddT12:41:29.000000Z, so this is as expected. Time of the video shown in the camera is 14:41, so also as expected.

Now comes the weird part:

API entry /gopro/camera/get_date_time returns:

{
    "date": "<today>",
    "time": "<now>",
    "tzone": 120,
    "dst": 1
}

Note that tzone is listed as 120, rather than the +1h=60m from the camera config menu.
I think that if a dst flag is present, that information shouldn't be duplicated into the timezone offset value.

API entry /gopro/media/list for said video returns "cre"/"mod" values 'seconds since epoch' which are 7200s=120m=2h later than the correct timestamp mentioned above (to be more precise, it is 7185 sec).
It seems that timezone offsets are incorrectly applied to the 'epoch'-related timestamps (Unix epoch is UTC-based, see https://en.wikipedia.org/wiki/Unix_epoch).
The exfat on-disk CreateTimestamp is 12:41:27.76, so (approx) expected UTC timestamp with no timezone offsets specified.

One would expect that the create/modified timestamps describe the start and end of the video. While the exfat file timestamps do exactly that, the timestamps delivered in the /gopro/media/list API always contain the identical value vor "cre" and "mod", see also the example in the API docu.