Question: --since date parsing uses current time instead of midnight - by design?

Hello,

I've just noticed how git log --since=<date> interprets dates without explicit times, and I found the behavior seems potentially unintended. I'd like to understand if this is by design or a bug.

When using --since="2026-02-09" (date without time), Git uses the current local time at command execution, not midnight (00:00:00) as users might expect.

For example:

     Running git log --since="2026-02-09" at 21:20:00 interprets it as 
"2026-02-09 21:20:00"

     Running the same command at 09:00:00 interprets it as "2026-02-09 
09:00:00"

This means the same command returns different results depending on when it's executed.

Root Cause (in date.c)

The issue stems from the two-stage parsing in approxidate_careful():
1) parse_date_basic() parses the date fields (year, month, day) but 
fails because time fields remain at -1, causing tm_to_time_t() to return -1
2) Falls back to approxidate_str(), which:
   - Calls localtime_r() to initialize tm with current time
   - Resets only date fields to -1 (year, mon, mday)
   - Re-parses the string, overwriting date fields
   - Time fields retain values from current local time
   - update_tm() calls mktime() with this mixed result

Is this behavior intentional? The approxidate mechanism is designed to be "human-friendly," but this seems like an edge case where users likely expect --since="2026-02-09" to mean midnight.

Explicitly specifying the time works correctly as a workaround:

--since="2026-02-09 00:00:00" --since="2026-02-09T00:00:00"

Should this behavior be documented, or would a patch to default to midnight be appropriate?

Regards, Gregor