System details

Browser Version: RStudio, Google Chrome

Output of sessionInfo():

R version 4.2.0 (2022-04-22)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Monterey 12.4

Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] shiny_1.7.1.9003

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.8.3     withr_2.5.0      digest_0.6.29    later_1.3.0      mime_0.12       
 [6] R6_2.5.1         jsonlite_1.8.0   lifecycle_1.0.1  xtable_1.8-4     magrittr_2.0.3  
[11] cachem_1.0.6     rlang_1.0.2      cli_3.3.0        promises_1.2.0.1 jquerylib_0.1.4 
[16] bslib_0.3.1      ellipsis_0.3.2   tools_4.2.0      httpuv_1.6.5     fastmap_1.1.0   
[21] compiler_4.2.0   htmltools_0.5.2  sass_0.4.1      

Example application or steps to reproduce the problem

library(shiny)
shinyApp(
  ui = basicPage(
    textOutput("date_out"),
    dateInput("date_in", "Date input", "2000-01-01")
  ),
  server = function(input, output, session) {
    output$date_out <- renderText(as.character(input$date_in))
  }
)

Click into the text field of the date input and press backspace; the date displayed will be 1999-12-31. Press backspace again; it will be today's date. Continue pressing backspace; it will be null when the field is empty.

Describe the problem in detail

dateInput (and dateRangeInput) eagerly try to parse incomplete date strings as they are being typed, and then send off the results to the server. This can have the effect of the server trying to process a date completely different from the one that the user intended to enter. In the case of a range, this can result in a min and max in the wrong order; and with a cleared-out field that the user intends to start typing a new date in, the server sees a null value. The server will then take actions with the bogus date before the user is even finished typing (some of which may prevent the user from completing their typing, e.g. updating the input to be in the "correct" order or throwing an error for a null date).

This might stem from JavaScripts officially undefined behavior when parsing nonstandard datestrings; I'd recommend ignoring typed input in this field until the user presses enter or unfocuses the field; or only updating when the current string matches the set format.