]> git.ipfire.org Git - thirdparty/git.git/commit
approxidate: make "specials" respect fixed day-of-month
authorTuomas Ahola <taahol@utu.fi>
Thu, 21 May 2026 10:54:07 +0000 (13:54 +0300)
committerJunio C Hamano <gitster@pobox.com>
Thu, 21 May 2026 13:30:05 +0000 (22:30 +0900)
commitbbe9b46ac826b5dad4f714513638dd223b6fe63f
tree69c758a13226967d641ee51441ac0fb3c7672596
parentd5ba64d8b5bb76402a64af2b780780de952de2b9
approxidate: make "specials" respect fixed day-of-month

The special approxidate time formats, "noon" and "tea" differ from
"12pm" and "5pm" by having the feature of wrapping to the previous day
if the current time is before those hours:

now  -> 2026-05-13 11:00:00 +0000

12pm -> 2026-05-13 12:00:00 +0000
5pm  -> 2026-05-13 17:00:00 +0000

noon -> 2026-05-12 12:00:00 +0000
tea  -> 2026-05-12 17:00:00 +0000

However, that logic carries too far.  Even when the date is specified,
the behavior of the "specials" depends on the current time.  Assuming
the same time as above, we get:

today at noon -> 2026-05-12 12:00:00 +0000 (should be 13 May)
13 May at tea -> 2026-05-12 17:00:00 +0000

or, using an example mentioned in date-formats.adoc:

last Friday at noon -> 2026-05-07 12:00:00 +0000 (should be 8 May)

The quirk seems to be rather old.  Already in 2006, Linus Torvalds
remarked that the date yielded by "one year ago yesterday at tea-time"
was "just silly and not even correct".  Indeed, even today it gives:

One year ago yesterday at tea-time -> 2025-05-11 17:00:00 +0000
  (should be 12 May)

Let's fix all of those with a simple patch.  Check whether we already
have a specified day-of-month in `tm->tm_mday` and make `date_time()`
stick to it.  Ensure the correct behavior with relevant tests.

Links:
  1. https://lore.kernel.org/git/Pine.LNX.4.64.0610101102560.3952@g5.osdl.org/

Signed-off-by: Tuomas Ahola <taahol@utu.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
date.c
t/t0006-date.sh