You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: