Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-11 Thread Martin Maechler
> Ben Bolker > on Mon, 10 Oct 2022 16:59:35 -0400 writes: > Right now as.POSIXlt.Date() is just > function (x, ...) > .Internal(Date2POSIXlt(x)) It has been quite a bit different in R-devel for a little while. NEWS entries (there are more already, and more coming on

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Jeff Newmiller
I have no idea how to get readxl::read_excel to import a timestamp column in a timezone. It is true that Excel has no concept of timezones, but the data one finds there usually came from a text file at some point. Importing as character is a feasible strategy, but trying to convince an

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Ben Bolker
Right now as.POSIXlt.Date() is just function (x, ...) .Internal(Date2POSIXlt(x)) How expensive would it be to throw a warning when '...' is provided by the user/discarded ?? Alternately, perhaps the documentation could be amended, although I'm not quite sure what to suggest. (The sentence

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Alexandre Courtiol
Hi Simon, Thanks for the clarification. >From a naive developer point of view, we were initially baffled that the generic as.POSIXlt() does very different things on a character and on a Date input: as.POSIXlt(as.character(foo), "Europe/Berlin") [1] "1992-09-27 CEST" as.POSIXlt(foo,

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Simon Urbanek
Liam, I think I have failed to convey my main point in the last e-mail - which was that you want to parse the date/time in the timezone that you care about so in your example that would be > foo <- as.Date(33874, origin = "1899-12-30") > foo [1] "1992-09-27" > as.POSIXlt(as.character(foo),

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-10 Thread Hadley Wickham
On Sun, Oct 9, 2022 at 9:31 PM Jeff Newmiller wrote: > > ... which is why tidyverse functions and Python datetime handling irk me so > much. > > Is tidyverse time handling intrinsically broken? They have a standard > practice of reading time as UTC and then using force_tz to fix the "mistake".

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-09 Thread Jeff Newmiller
... which is why tidyverse functions and Python datetime handling irk me so much. Is tidyverse time handling intrinsically broken? They have a standard practice of reading time as UTC and then using force_tz to fix the "mistake". Same as Python. On October 9, 2022 6:57:06 PM PDT, Simon

Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-09 Thread Simon Urbanek
Alexandre, it's better to parse the timestamp in correct timezone: > foo = as.POSIXlt("2021-10-01", "UTC") > as.POSIXct(as.character(foo), "Europe/Berlin") [1] "2021-10-01 CEST" The issue stems from the fact that you are pretending like your timestamp is UTC (which it is not) while you want to