search

inbo / camtraptor

Camtraptor is an R package to read, explore and visualize Camera Trap Data Packages (Camtrap DP)
https://inbo.github.io/camtraptor/
MIT License
10 stars 2 forks source link

Preserve GMT offset #188

Open damianooldoni opened 1 year ago

damianooldoni commented 1 year ago

From @MarcusRowcliffe mail, Nov 2, 2022:

I believe importing data using read_cameratrap_dp sets observations$timestamp time zone to UTC, adjusting the time according to the GMT offset at the end of the original character timestamp values. Is that GMT offset value preserved anywhere in the data?

My answer via mail for reference:

the function uses the function read_resource() from the frictionless package behind the hood with default arguments: see line of code for deployments rsource as example. However, read_resource() supports several field types such as timestamps with timezones (so other than UTC timestamps). As read_camtrap_dp doesn't expose this field types to the user it seems indeed that only UTC is supported now.

@MarcusRowcliffe: In example of camtrap-dp I can indeed see how GMT offset is part of the datetime, e.g. 2020-05-30T04:57:37+02:00. I will work to allow importing these datetimes as they are in the data package next week! Thanks for reporting this and sorry for the delay.

damianooldoni commented 1 year ago

Hi @MarcusRowcliffe, I hoped it was something I could solve both easily and elegantly at camtraptor level or at frictionless level, but it seems something at readr level. Or at least that's my opinion. I will see what the maintainer of readr, Jim Hester, answers. See https://github.com/tidyverse/readr/issues/1465

Depending on what you really need, here a workaround:

library(dplyr)
library(camtraptor)
library(lutz) #package to get offset from POSIXct objects

camtrap_dp_file <- system.file("extdata", "mica", "datapackage.json", package = "camtraptor")
muskrat_coypu <- read_camtrap_dp(camtrap_dp_file)

muskrat_coypu$data$deployments$start_clocktime <- lubridate::with_tz(muskrat_coypu$data$deployments$start, tz="Europe/Brussels")

muskrat_coypu$data$deployments$start
#> [1] "2020-07-29 05:29:41 UTC" "2020-06-19 21:00:00 UTC"
#> [3] "2021-03-27 20:38:18 UTC" "2019-10-09 11:18:07 UTC"
muskrat_coypu$data$deployments$start_clocktime
#> [1] "2020-07-29 07:29:41 CEST" "2020-06-19 23:00:00 CEST"
#> [3] "2021-03-27 21:38:18 CET"  "2019-10-09 13:18:07 CEST"

muskrat_coypu$data$deployments$start_offset_in_hrs <- lutz::tz_offset(muskrat_coypu$data$deployments$start_clocktime)$utc_offset_h
muskrat_coypu$data$deployments$start_offset_in_hrs
#> [1] 2 2 1 2

Questions are:

  1. @MarcusRowcliffe: is start_offset_in_hrs what you had in mind? Or is the clocktime (with tzone like CET) enough?
  2. should we go for a function to add *_clocktime functions where needed? Probably yes.
  3. should we add such columns to all resources while reading a package? I prefer to not do it as I am not in favor of adding more non standard columns. A function properly documented as described in 2 is enough I think.