From: gregor@chkpnt.de
Date: Fri, 13 Feb 2026 21:09:29 GMT
Subject: Question: --since date parsing uses current time instead of midnight - by design?
Message-ID: <e5904a7b-c146-4c36-8b87-c5c508e14cca@chkpnt.de>

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