threads / discuss / 64993

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

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

## tl;dr

3 messages between Feb 13, 2026 and Feb 14, 2026.

replies: 2people: 2as markdown or json

gregor@chkpnt.de· Feb 13, 2026, 21:09 UTC · lore
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

Junio C Hamano· Feb 13, 2026, 22:41 UTC · re: gregor@chkpnt.de · lore

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

gregor@chkpnt.de writes:
Show 5 quoted lines
> 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.
Looks like it is very much designed, ...
https://lore.kernel.org/git/Pine.LNX.4.64.0511171505080.13959@g5.osdl.org/
... at least to me.
Junio C Hamano· Feb 14, 2026, 22:11 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 13 quoted lines
> gregor@chkpnt.de writes:
>
>> 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.
>
> Looks like it is very much designed, ...
>
> https://lore.kernel.org/git/Pine.LNX.4.64.0511171505080.13959@g5.osdl.org/
>
> ... at least to me.

With hindsight, it looks to me that both conventions are equally legit. If you extend a low-resolution time specification (e.g., date only without hours and minutes) to use the current time, which is what Linus decided to do, that is one valid convention. You can choose to extend lower bits to zero (e.g., date only without hours and minutes means midnight at the beginning of that day), that is equally valid.

The former, however, is more convenient than the latter for humans. You can ask "what did we in the past 24-hours?" more easily. And if you really care to give the midnight, filling the lower bits to zero yourself is not that hard, compared to having to fill the lower bits with the current time. So it would be an overall win for both use cases.

← back to recent threads