Although some commands do reject invalid approxidate expressions, in other cases those are simply evaluated as the current time. Oftentimes that is a perfectly good compromise to handle silly requests, but it isn't without rough edges.

Let's consider what "git log --since=today" should yield. As it happens that "today" isn't actually a valid approxidate format, the command currently tries to list commits with *future* timestamps. Perhaps it would make more sense if it returned the commits made since midnight---that is, during the current day.

Moreover, a revision parameter "@{today}" is currently outright rejected. Making "today" a valid approxidate time format could make a natural way to specify the state of the ref at the start of the current day.

Bind "today" to new function `date_today()` as an approxidate special. Make it return the last midnight if no specific time is given; i.e. retain the old behavior of "noon today" and such.

Signed-off-by: Tuomas Ahola <taahol@utu.fi>
---

Notes:
    The "Jan 5 today" test is adapted from
    
      c27cc94fad (approxidate: handle pending number for "specials", 2018-11-02):
    
    > (saying "Jan 5 yesterday" should not respect the number at all).

 date.c          | 10 ++++++++++
 t/t0006-date.sh |  2 ++
 2 files changed, 12 insertions(+)

Tuomas Ahola <taahol@utu.fi> writes:

I actually am of two minds about this.  

What should "git log --until=today" do when you run it in the late afternoon? Wouldn't you want to see what you did in the morning and early afternoon?

Because we cannot define "today" as "--since=today means the latest midnight and later, while --until=today means until the end of today [*]" without introducing an extra hint to calls to approxidate() to tell it who is calling for what, it is impossible to give these two sensible behavior at the same time.

    Side note: but because the existing history is all about the past,
    "until the end of today" is by definition a synonym for "up to
    now", so defining "today" the same as "now" would make "until"
    behave just as sensibly as if we define it as "the end of today".

In practice, using "--until" to *not* truncate at all (which is what --until=now or --until=end.of.today would essentially mean) has no practical value, while "--since=beginning.of.today" does have more utility, allowing you to specify "the last 8 hours and 50 minutes" without knowing that it is now at 08:50 in the morning. So I am still in favor of interpreting "today" as "the latest midnight, the beginning of today" because that would give us a more useful behavior than other possible definitions. We may want to strengthen the justification behind the chosen definition of why we chose what we chose over any other time in today with something like what I said above, mentioning "--until".

Thanks.

Although some commands do reject invalid approxidate expressions, in other cases those are simply evaluated as the current time. Oftentimes that is a perfectly good compromise to handle silly requests, but it isn't without rough edges.

Because of the silent acceptance, it is easy to forget that "today" isn't actually a valid approxidate format. That is a bit awkward because while the fallback logic of using the current time does make some sense, there is no deliberative decision behind such behavior of "today". Indeed, whatever (non-)action "today" currently has, is just an accidental side effect.

That means "git log --since=today" is currently unlikely to print anything at all as it tries to list commits dated with *future* timestamps. Arguably it would be more useful to list the commits of the current day---i.e. those made since midnight.

On the other hand, "git log --until=today" doesn't really filter commits at all. Changing the definition of "today" would make it return the commits made before the current day. That isn't without problems though---running "git log --until=today" in the late afternoon could reasonably include the work done earlier that day (as the command currently does do).

Still the utility of no-op "--until=today" is debatable and perhaps outweighed by the pros of having "--since=today" to mean "--since=midnight". The thing is that the approxidate machinery doesn't know about its consumers, so the meaning of "today" has to be the same for "--since" and "--until".

In fact, "git log --until=" is documented as

	`--until=<date>`::
	`--before=<date>`::
		Show commits older than _<date>_,

so excluding commits made today would actually match the documentation more closely.

Moreover, a revision parameter "@{today}" is currently outright rejected. Making "today" a valid approxidate time format could make a natural way to specify the state of the ref at the start of the current day.

Bind "today" to new function `date_today()` as an approxidate special. Make it return the last midnight if no specific time is given; i.e. retain the old behavior of "noon today" and such.

Document the new behavior of "git log --since=today" in rev-list-options.adoc.

Signed-off-by: Tuomas Ahola <taahol@utu.fi>
---
Intervall-diff mot v1:
1:  849f058baf ! 1:  86bcb70ac2 approxidate: make "today" wrap to midnight
    @@ Commit message
         Oftentimes that is a perfectly good compromise to handle silly
         requests, but it isn't without rough edges.
     
    -    Let's consider what "git log --since=today" should yield.
    -    As it happens that "today" isn't actually a valid approxidate
    -    format, the command currently tries to list commits with
    -    *future* timestamps.  Perhaps it would make more sense if
    -    it returned the commits made since midnight---that is,
    -    during the current day.
    +    Because of the silent acceptance, it is easy to forget that
    +    "today" isn't actually a valid approxidate format.  That is
    +    a bit awkward because while the fallback logic of using the
    +    current time does make some sense, there is no deliberative
    +    decision behind such behavior of "today".  Indeed, whatever
    +    (non-)action "today" currently has, is just an accidental
    +    side effect.
    +
    +    That means "git log --since=today" is currently unlikely to
    +    print anything at all as it tries to list commits dated with
    +    *future* timestamps.  Arguably it would be more useful to
    +    list the commits of the current day---i.e. those made since
    +    midnight.
    +
    +    On the other hand, "git log --until=today" doesn't really
    +    filter commits at all.  Changing the definition of "today"
    +    would make it return the commits made before the current day.
    +    That isn't without problems though---running "git log
    +    --until=today" in the late afternoon could reasonably include
    +    the work done earlier that day (as the command currently
    +    does do).
    +
    +    Still the utility of no-op "--until=today" is debatable and
    +    perhaps outweighed by the pros of having "--since=today" to
    +    mean "--since=midnight".  The thing is that the approxidate
    +    machinery doesn't know about its consumers, so the meaning
    +    of "today" has to be the same for "--since" and "--until".
    +
    +    In fact, "git log --until=" is documented as
    +
    +            `--until=<date>`::
    +            `--before=<date>`::
    +                    Show commits older than _<date>_,
    +
    +    so excluding commits made today would actually match the
    +    documentation more closely.
     
         Moreover, a revision parameter "@{today}" is currently outright
         rejected.  Making "today" a valid approxidate time format could
    @@ Commit message
         special.  Make it return the last midnight if no specific time
         is given; i.e. retain the old behavior of "noon today" and such.
     
    +    Document the new behavior of "git log --since=today" in
    +    rev-list-options.adoc.
    +
         Signed-off-by: Tuomas Ahola <taahol@utu.fi>
     
    + ## Documentation/rev-list-options.adoc ##
    +@@ Documentation/rev-list-options.adoc: ordering and formatting options, such as `--reverse`.
    + 
    + `--since=<date>`::
    + `--after=<date>`::
    +-	Show commits more recent than _<date>_.
    ++	Show commits more recent than _<date>_.  As a special case,
    ++	'today' means the last midnight.
    + 
    + `--since-as-filter=<date>`::
    + 	Show all commits more recent than _<date>_. This visits
    +
      ## date.c ##
     @@ date.c: static void date_never(struct tm *tm, struct tm *now UNUSED, int *num)
      	*num = 0;

 Documentation/rev-list-options.adoc |  3 ++-
 date.c                              | 10 ++++++++++
 t/t0006-date.sh                     |  2 ++
 3 files changed, 14 insertions(+), 1 deletion(-)

Tuomas Ahola <taahol@utu.fi> writes:

I like this construction of argument.

How does this patch mesh with your earlier effort to make "noon" and "tea" more sensible? Should we eject the "today is now" step from that series and instead queue this patch in its place?

Thanks.

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

Yes. I have already rebased the series on top of this patch. I will soon(ish) post v4 without "today is now" step.

--Tuomas