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