While it makes sense for to_date() to be strict about requiring the full-date format, stabilize_date() must be flexible about inputs; that's a major point of this package ("Be conservative in what you send. Be liberal in what you accept from others."). Add an argument to stabilize_date(), stabilize_date_scalar(), specify_date(), etc, accepted_datetime_formats, similar to the tryFormats argument of base::as.POSIXlt(). The default value should use a helper function to figure out the order of expected formats, something like locale_datetime_formats(locale_time = Sys.getlocale("LC_TIME")). I think from that we can figure out whether to use %m/%d/%Y vs %d/%m/%Y by default. The helper will return a character vector of allowed formats, always starting with "%Y-%m-%d" (well, technically start with the version of that that includes HMS, see below for why), but also including the locale's format (with both / and - separators). Also allow for time components of each of those, as in the tryFormats parameter. Then, in stabilize_date(), we'll try each allowed format in order to see if any work. Throw an error if no single format works for all elements of the input vector.
Do the same for the other date/time stabilize_*() functions (using the same locale_datetime_formats() helper, thus why we should return the date + time option first from this). You may find other helpers to extract for this conversion process (for example, for trying the different formats and reporting clean errors).
This will break / render irrelevant some existing tests, which expect stabilize_*() date-time functions to always fail for "ambiguous" dates. That is expected. Those tests should be removed.
This is being implemented in the same release as the initial release of the date/time functions, so don't mention it in NEWS.
While it makes sense for
to_date()to be strict about requiring thefull-dateformat,stabilize_date()must be flexible about inputs; that's a major point of this package ("Be conservative in what you send. Be liberal in what you accept from others."). Add an argument tostabilize_date(),stabilize_date_scalar(),specify_date(), etc,accepted_datetime_formats, similar to thetryFormatsargument ofbase::as.POSIXlt(). The default value should use a helper function to figure out the order of expected formats, something likelocale_datetime_formats(locale_time = Sys.getlocale("LC_TIME")). I think from that we can figure out whether to use%m/%d/%Yvs%d/%m/%Yby default. The helper will return a character vector of allowed formats, always starting with"%Y-%m-%d"(well, technically start with the version of that that includes HMS, see below for why), but also including the locale's format (with both/and-separators). Also allow for time components of each of those, as in thetryFormatsparameter. Then, instabilize_date(), we'll try each allowed format in order to see if any work. Throw an error if no single format works for all elements of the input vector.Do the same for the other date/time
stabilize_*()functions (using the samelocale_datetime_formats()helper, thus why we should return the date + time option first from this). You may find other helpers to extract for this conversion process (for example, for trying the different formats and reporting clean errors).This will break / render irrelevant some existing tests, which expect
stabilize_*()date-time functions to always fail for "ambiguous" dates. That is expected. Those tests should be removed.This is being implemented in the same release as the initial release of the date/time functions, so don't mention it in NEWS.