bug(date): Weird behavior -d vs -f in some cases

Hi, uutils mainteners

there was in our tests very weird behavior of the date command

relunsec@relunsec:~/software/coreutils/target/debug$  echo "2026-06-15 ( foo" > dates.txt   
relunsec@relunsec:~/software/coreutils/target/debug$ ./date -f dates.txt 
date: invalid date '2026-06-15 ( foo'
relunsec@relunsec:~/software/coreutils/target/debug$ ./date -d "2026-06-15 ( foo"
Mon Jun 15 12:00:00 AM EDT 2026
relunsec@relunsec:~/software/coreutils/target/debug$ 

that is test 1 as you can see there was a difference between -d and -f

and also with too test 2

relunsec@relunsec:~/software/coreutils/target/debug$ ./date -d ""
Mon Jun 15 12:00:00 AM EDT 2026
relunsec@relunsec:~/software/coreutils/target/debug$ echo "" > dates.txt   
relunsec@relunsec:~/software/coreutils/target/debug$ ./date -f dates.txt
Mon Jun 15 04:00:37 AM EDT 2026
relunsec@relunsec:~/software/coreutils/target/debug$ ./date -f dates.txt --debug
date: input string: 
date: parsed date part: (Y-M-D) 2026-06-15
date: parsed time part: 04:00:54
date: input timezone: system default
Mon Jun 15 04:00:54 AM EDT 2026

as yu can see in -f with a file it is Monday june 15 04:00:37 while with empty -d produces the default 12:00:00AM assumed time

our test confirms in some cases -f not like -d behavior they need match

Start by reproducing the two reported cases with the date entry point and dates.txt, comparing -d with -f and using --debug for the file input. Trace where each option parses empty and malformed input; done means their behavior matches in these cases and regression tests cover both examples.