Should ymd() and similar return a date? #391
The text was updated successfully, but these errors were encountered:
I have implemented this locally and realized that it leads to some ocassionall inconveniences.
When you need a POSIX object with HMS of
Our with_tz doesn't help either:
So you would need:
So I am leaving
I am also leaving truncation functions alone for now. Till we have a clean and fast way to jump between Date and POSIX it's looks like bringing more hustle than it solves. Maybe we should consider a reverse of new
This change might break existing ggplot visuals that plot according to a date variable and use some kind of scale_*_date().
Before you could get away with ymd("2013-01-01") type entries in your data frame and also in your scale_*_date(), and everything would work as expected. Now if you are plotting dates and want to adjust the scale, both the data frame and the argument to the scale function need a tz argument like ... ymd("2013-01-01", tz = "UTC").
Maybe ggplot2 could be updated to more gracefully handle Date objects (tz not specified, instead of POSIXct) as it effectively was doing before lubridate was updated??
@hadley this change had an unfortunate impact on comparison operators:
I think comparing Date and POSIX objects makes sense. So, I am considering overwriting Date Ops generic. What do you think?
Thanks for looking in to this!
It looks like you have already nailed down the underlying problem, but here
works for all versions
df <- data.frame(Date = ymd(c(20151231, 20160131, 20160228, 20160331)),
only works with older versions of lubridate
p <- p + scale_x_datetime(breaks = ymd(c("20160115", "20160215",
you will see this error message when using newer versions ...
#Error: Invalid input: time_trans works with objects of class POSIXct only
update required to work with new and old lubridate.
note the tz argument in both the data and the scale_x_datetime() function
df <- data.frame(Date = ymd(c(20151231, 20160131, 20160228, 20160331), tz =
On Sun, May 8, 2016 at 12:03 PM, Hadley Wickham firstname.lastname@example.org
I spent a good part of the night figuring how to do that. Nor S4 Compare group generic, nor S3 Ops worked as advertised. I eventually got all comparisons manually registered. Seem to work as expected now.
Let's wait and see if this has any undesirable effects, and then propose to R-core.
I would say no, "2016-08-30 EDT" is not meaningful generally.
On the other hand, with global weather or financial data, the difference
On Tue, Aug 30, 2016 at 1:38 PM, Abraham Neuwirth email@example.com