> 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 th
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 intermedi
Hi:
I have some doubts on how to proceed in this case. I am the developer of
tidyterra, and I received an email from CRAN on 23Sep2022 about an issue on
the package, setting a deadline on 07Oct2022 to correct it.
I sent a patch that was accepted on CRAN on 29Sep2022, that fixed the issue
(or at l
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
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, "Europe/Berl
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), "Eur
Hi all,
I'd like to link to a help page of a package in my package's Suggests.
WRE, section 2.5 says,
"Historically (before R version 4.1.0), links of the form
\link[pkg]{foo} and \link[pkg:bar]{foo} used to be interpreted as
links to files foo.html and bar.html in package pkg, respectively. For
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".
Good day,
I am developing a wrapper around xgboost which does not (yet - I see that it is
on the developer's version 2.0 task list) support factor variable type. It
requires input data to be in one-hot encoding, which is created by
Matrix::sparse.model.matrix. For further analysis, such as vari
