public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
* Question: --since date parsing uses current time instead of midnight - by design?
@ 2026-02-13 21:09 gregor
  2026-02-13 22:41 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: gregor @ 2026-02-13 21:09 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question: --since date parsing uses current time instead of midnight - by design?
  2026-02-13 21:09 Question: --since date parsing uses current time instead of midnight - by design? gregor
@ 2026-02-13 22:41 ` Junio C Hamano
  2026-02-14 22:11   ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2026-02-13 22:41 UTC (permalink / raw)
  To: gregor; +Cc: git

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question: --since date parsing uses current time instead of midnight - by design?
  2026-02-13 22:41 ` Junio C Hamano
@ 2026-02-14 22:11   ` Junio C Hamano
  0 siblings, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2026-02-14 22:11 UTC (permalink / raw)
  To: gregor; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> 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.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-02-14 22:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-13 21:09 Question: --since date parsing uses current time instead of midnight - by design? gregor
2026-02-13 22:41 ` Junio C Hamano
2026-02-14 22:11   ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox