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

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

2022-10-09 Thread Alexandre Courtiol
Hi R pkg developers, We are facing a datetime handling issue which manifests itself in a package we are working on. In context, we noticed that reading datetime info from an excel file resulted in different data depending on the computer we used. We are aware that timezone and regional settings