scale_x_date passes NAs to the label function

[ggrothendieck]

When using scale_x_date(..., label = fun) it can be that NAs are passed to fun which adds undesirable complexity to the definition of the function.

See this example:
https://stackoverflow.com/questions/44616530/prevent-showing-the-year-several-times-unnecessarily-with-time-series/44751923#44751923

where this line had to be added to avoid errors even though the NAs do not actually correspond to breaks:

b[is.na(b)] <- Sys.Date()

Any date could have been used in place of Sys.Date() since it seems that the date itself is not actually used if the passed break is NA.

[karawoo]

Could you please provide a minimal reproducible example using the reprex package? I'm having trouble reproducing the example from that SO link.

[ggrothendieck]

This fails with an error message.; howver, if we uncomment the line containing Sys.Date() then it works. The problem seems to be that ggplot2 passes a vector containing some NA components to the lab function and one must provide a valid label for them even though ggplot2 never uses those labels. ggplot2 should not pass these NA values to the label function.

    library(ggplot2)
    library(scales)

    # test input
    df <- data.frame(Date = as.Date(c("1719-08-10", "1720-11-25")), value = 0:1)

    lab <- function(b) {
      print(b)  # note NA components of b
      # b[is.na(b)] <- Sys.Date()  # uncomment this line and it will work
      format(b, ifelse(as.POSIXlt(b)$mon == 0, "%Y", "%b"))
    }

    ggplot(df, aes(Date, value)) + 
       geom_line() +
       scale_x_date(date_breaks = "month", labels = lab)

The output of the print statement (in the lab function) upon running the above code is shown below. Note the NA values that were passed to lab unnecessarily complicating the lab function's code.

 [1] NA           "1719-08-01" "1719-09-01" "1719-10-01" "1719-11-01"
 [6] "1719-12-01" "1720-01-01" "1720-02-01" "1720-03-01" "1720-04-01"
[11] "1720-05-01" "1720-06-01" "1720-07-01" "1720-08-01" "1720-09-01"
[16] "1720-10-01" "1720-11-01" "1720-12-01" NA 

[hadley]

The root cause is that the breaks algorithm generates breaks that are outside of the limits, and these get converted to NAs. It would be possible to fix this problem but it would require modifying code that I no longer understand and is probably not terribly well tested. Given that there's an existing work around (make sure your labelling function can handle NAs), unfortunately I don't think it's worthwhile to try and fix this bug.