[Rd] Date class shows Inf as NA; this confuses the use of is.na()
Joris Meys
jori@mey@ @ending from gm@il@com
Mon Jun 11 12:00:48 CEST 2018
On Mon, Jun 11, 2018 at 11:12 AM, Martin Maechler <
maechler using stat.math.ethz.ch> wrote:
>
> and a Date vector *is* atomic .. (so I'm confused about what
> that issue is .. but read one.
>
Indeed. I tend to exclude everything with a formal class from "atomic" (eg
factors et al) because they do behave differently sometimes, but
technically that's not correct. Thank you for pointing that out.
> Indeed. I could argue it is wrong to treat '+/- Inf' as NA for
> dates (as well as for date times), because the Inf *does*
> contain information in some sense:
>
> Infinitely far in the future
> vs Infinitely far in the past
>
> which may make sense in some case ... in the same sense +Inf and
> -Inf do make sense for numbers in some cases.
>
> Martin
>
I considered that too. But as shown in the code above: anything that relies
on POSIXlt to process the date, will actually convert the Inf value to NA.
The problem becomes a bit more confusing, as as.POSIXct() does not convert
to NA.
> x <- as.Date(Inf, origin = '1970-01-01')
> is.na(x)
[1] FALSE
> is.na(as.POSIXct(x))
[1] FALSE
> is.na(as.POSIXlt(x))
[1] TRUE
I can guess why this happens. For a date that's infinitely far in the
future, it is impossible to determine an exact hour, minute, second, day,
month, ... So these values in the POSIXlt "list" format can't be anything
but NA.
So I totally understand the value of having Inf dates. The trade-off to
consider here is whether we strive for consistency among the different
datetime classes, or strive for correct representation of the actual value
of the date.
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
More information about the R-devel
mailing list