r-lib / clock

A Date-Time Library for R
https://clock.r-lib.org
Other
97 stars 4 forks source link

date_time_build not erroring as documented #293

Closed TimTaylor closed 2 years ago

TimTaylor commented 2 years ago

In the documentation for date_time_build() we have (emphasis mine)

Note that clock always assumes that R's Date class is naive, so converting a Date to a POSIXct will always attempt to retain the printed year, month, and day. Where possible, the resulting time will be at midnight (00:00:00), but in some rare cases this is not possible due to daylight saving time. If that issue ever arises, an error will be thrown, which can be resolved by explicitly supplying nonexistent or ambiguous.

This works

as.Date("2039-04-03") |> clock::as_date_time(zone="NZ", nonexistent="error", ambiguous="error")
#> [1] "2039-04-03 NZDT"

but I'd expect the following to error

as.Date("2039-04-04") |> clock::as_date_time(zone="NZ", nonexistent="error", ambiguous="error")
#> [1] "2039-04-04 01:00:00 NZDT"

I suspect this is related to something which changes in R formatting in 2039 (see #292 which I closed as began to suspect that was an R not clock issue).

TimTaylor commented 2 years ago

Apologies - closing this as well. This seems to be an issue only in Ubuntu 18.04, not latest Fedora or MacOS so suspect it's something to do with system libraries.

DavisVaughan commented 2 years ago

Yea to confirm, this returns the right result on my Mac, so I suppose it may just be some kind of printing but on Ubuntu

as.Date("2039-04-04") |> clock::as_date_time(zone="NZ", nonexistent="error", ambiguous="error")
#> [1] "2039-04-04 NZST"

Created on 2022-02-28 by the reprex package (v2.0.1)