GH-35633: [R] R builds failing with error 'Invalid: Timestamps already have a timezone: 'UTC'. Cannot localize to 'UTC''

[paleolimbot]

Alternative approach to #35634.

• Closes: [R] R builds failing with error 'Invalid: Timestamps already have a timezone: 'UTC'. Cannot localize to 'UTC'' #35633

[github-actions]

• Closes: [R] R builds failing with error 'Invalid: Timestamps already have a timezone: 'UTC'. Cannot localize to 'UTC'' #35633

[thisisnic]

Thanks!

[ursabot]

Benchmark runs are scheduled for baseline = dd33cab and contender = 9039ee2. 9039ee2 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.21% ⬆️0.03%] test-mac-arm
[Finished ⬇️2.29% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.12% ⬆️0.24%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 9039ee2c ec2-t3-xlarge-us-east-2
[Finished] 9039ee2c test-mac-arm
[Finished] 9039ee2c ursa-i9-9960x
[Finished] 9039ee2c ursa-thinkcentre-m75q
[Finished] dd33cabd ec2-t3-xlarge-us-east-2
[Finished] dd33cabd test-mac-arm
[Finished] dd33cabd ursa-i9-9960x
[Finished] dd33cabd ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[ursabot]

['Python', 'R'] benchmarks have high level of regressions.
ursa-i9-9960x

[jorisvandenbossche]

I don't understand how timezones work in R (and with POSIXlt and POSIXct), but with the above change, the tz keyword will just be ignored when the string includes an offset?

That doesn't match fully what base R does:

> strptime("2020-05-01T00:00+0100", format="%Y-%m-%dT%H:%M%z")
[1] "2020-05-01 01:00:00"
> strptime("2020-05-01T00:00+0100", format="%Y-%m-%dT%H:%M%z", tz="US/Eastern")
[1] "2020-04-30 19:00:00"

(but again, I don't really know how to interpret those returned values, and whether they are tz "aware" or "native" or even if those concepts even exist in R. I looked at the $zone and $gmtoff attributes of the above return values, but can't make sense of it)

[paleolimbot]

We don't have a naive datetime type in R...everything is timezone aware, and tz = "" means "your local timezone" (but everything is UTC internally). What you've encountered here is a fun type called the POSIXlt which is sort of like a data frame that stores components in separate vectors (the POSIXct is a more normal version of it, which is seconds from the unix epoch as a double vector).

It's a good point that this doesn't match what base R does...I think we'd want to cast() if grepl("%z") and assume_timezone() otherwise?

[paleolimbot]

I don't know if this helps with understanding dates/times in R, but the tz argument won't affect the underlying point in time (just the attribute of the output and, to great confusion of many, how it is printed):

unclass(as.POSIXct(strptime("2020-05-01T00:00+0100", format="%Y-%m-%dT%H:%M%z")))
#> [1] 1588287600
#> attr(,"tzone")
#> [1] ""
unclass(as.POSIXct(strptime("2020-05-01T00:00+0100", tz = "UTC", format="%Y-%m-%dT%H:%M%z")))
#> [1] 1588287600
#> attr(,"tzone")
#> [1] "UTC"
unclass(as.POSIXct(strptime("2020-05-01T00:00+0100", tz = "America/Halifax", format="%Y-%m-%dT%H:%M%z")))
#> [1] 1588287600
#> attr(,"tzone")
#> [1] "America/Halifax"

^{Created on 2023-05-24 with reprex v2.0.2}

[jorisvandenbossche]

It's a good point that this doesn't match what base R does...I think we'd want to cast() if grepl("%z") and assume_timezone() otherwise?

Yes, that sounds correct