Closed mhpob closed 10 months ago
See discussion from https://github.com/ocean-tracking-network/glatos/pull/204#issuecomment-1904500529 onward.
It looks to be an issue with Daylight Saving Time. All standard times are correct, all DST have advanced an hour.
It seems that the issue was caused by coercion from POSIXlt to POSIXct with different tzone attributes in linux (not windows or mac). E.g, round.POSIXct()
returns POSIXlt object, which then passed to as.POSIXct()
. (also fwiw, considered lubridate::force_tz() but decided to stay base R to minimize external dependencies. Did not test force_tz on any OS).
e.g.,
On linux:
# timestamp from US/Eastern coming in as POSIXct with tzone = UTC (readxl behavior)
foo <- as.POSIXct(c("2024-05-02 18:43:50", "2024-05-02 19:00:30", "2024-05-02 20:07:10"), tz = "UTC")
foo
[1] "2024-05-02 18:43:50 UTC" "2024-05-02 19:00:30 UTC" "2024-05-02 20:07:10 UTC"
# coerce to POSIXlt then POSIXct with different time zone as.POSIXct(as.POSIXlt(foo), tz = "US/Eastern")
[1] "2024-05-02 19:43:50 EDT" "2024-05-02 20:00:30 EDT" "2024-05-02 21:07:10 EDT"
Note one hour shift.
On windows:
# same as above
as.POSIXct(as.POSIXlt(foo), tz = "US/Eastern")
[1] "2024-05-02 18:43:50 EDT" "2024-05-02 19:00:30 EDT" "2024-05-02 20:07:10 EDT"
But values as expected; no shift.
Perhaps this has to do with linux recognition of time zone names? e.g., the POSIXlt object has attribute:
$tzone [1] "US/Eastern" "EST" "EDT"
and POSIXct object has attribute:
$tzone [1] "US/Eastern"
Test on GitHub Actions fails on old/current/development versions of Ubuntu but passes on Windows and MacOS: https://github.com/ocean-tracking-network/glatos/actions/runs/7590506986/job/20677120018#step:6:2710