Implement sec.axis for date, time, and datetime scales

[dpseidel]

This PR implements secondary axes for date, time, datetime scales. Closes #2244.

[thomasp85]

Can you add an example showing a meaningful use of a Date transformation in the secondary axis?

[thomasp85]

It seems this check is now so common that it should be factored out into a separate function

[dpseidel]

Thanks @thomasp85.

4 things:

• As you suggested, I pulled out the checks into a standalone function. The name may need some tweaking, currently set_sec_axis().
• I've added two examples to the sec_axis() docs rather than to the scale_*_date() docs, just because that seemed more appropriate but I can move them around if people have strong feelings.
• To come up with examples, I perused the original issue. One of the suggested use cases in Allow dup_axis within scale_x_date #2244 was to have time since event on the secondary axis with datetime or date on the primary. This is not currently possible as a transformation per se because the api now sets the scale transformation of the secondary axis to match the primary's (rather than using the identity transformation); i.e. date scales expect dates and don't play nice with numeric or difftime objects. Regardless, this "time since event" axis can be implemented simply by passing a function to labels. Just thought it was worth noting this minor limitation of the current implementation.
• currently sec.axis does not respect date specific arguments e.g. date_labels or date_breaks or date_minor_breaks, instead requiring the user to implement these formatting choices with the scales functions manually. Does it make sense to add these arguments/functionality to sec.axis directly?

[hadley]

@thomasp85 can you please re-review?

[clauswilke]

@dpseidel For your last bullet point, do you mean adding these parameters to the function sec.axis() or adding a separate function, e.g. sec.axis.date(). The former seems a bad idea to me (since in most use cases the parameters would be useless) and the latter could be done but doesn't have to be part of this PR.

[dpseidel]

@clauswilke I was intending to inquire about the former solution -- adding these as arguments to sec.axis() just as they are arguments to scale_*_datetime() -- but I can see that being unnecessary and undesirable. The same functionality is achievable if you know how to specify date formatting using scales functions, it's just not as clean/convenient.

Thanks for all your work pushing out this bug release! This last one of mine is pretty close, I'm just waiting on a final review. I've synced this branch with master now and may add more tests today to bring the codecov percentage up but otherwise, we should be near finished.

[clauswilke]

@thomasp85 Any more comments from your end?

[thomasp85]

I’m going to do a review this evening

[thomasp85]

I think this is fine as-is. Agree that sec_axis() shouldn't get date specific arguments... Thanks for all your work on this Dana

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/