Today conditional date broken

[FilippoBonazziSUSE]

Expected Behaviour

The Conditional Date %[d for Today returns True if an email arrived today, e.g. the following expression:

%<[d?%[Today %R]&%[%F %R]>

prints Today HH:MM if the email date matches the current day, or YYYY-mm-DD HH:MM otherwise.

Let's say it is 9:00 now, an email that arrived yesterday at 11 prints

2024-04-25 11:00

Actual Behaviour

The Conditional Date %[d for Today returns True if an email arrived in the last 24 hours, e.g. the following expression:

%<[d?%[Today ]&%[%F]>

prints Today HH:MM if the email arrived in the last 24 hours, or YYYY-MM-DD HH:MM otherwise.

Let's say it is 9:00 now, an email that arrived yesterday at 11 prints

Today 11:00

This is wrong, and also looks absurd (today 11:00 has not happened yet if it is currently 9:00).

Steps to Reproduce

Configure a conditional date containing the Today %[d expression in index_format, such as:

set index_format="%4C %Z %<[d?%[Today      %R]&%[%F %R]> %-15.15L (%?l?%4l&%4c?) %s"

Observe an email received yesterday but less than 24 hours ago (e.g. yesterday at 11:00 while today it is 9:00).

How often does this happen?

• Always

When did it start to happen?

• When I upgraded from 20231221 to 20240416, still occurs on 20240425

I cannot be more precise now, as this is the update path that happened on openSUSE and I have not done any bisection yet. Hopefully it is not necessary.

Something must have been changed in the implementation of conditional dates (at least of the Today %[d date), so that now it returns true if the email date is less than 24 hours away from the current date, while it used to (and it should) return true if the email date matched the current date (YYYY-mm-DD == YYYY-mm-DD).

NeoMutt Version

I have tested on 20240425 and the error occurs there as well, but I don't have that -v output available right now. Here is the output of version 20240416 that I have installed on my system right now:

NeoMutt 20240416
Copyright (C) 2015-2024 Richard Russon and friends
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 6.8.7-1-default (x86_64)
ncurses: ncurses 6.4.20240414 (compiled with 6.4.20240414)
libidn2: 2.3.7 (compiled with 2.3.7)
GPGME: 1.23.2
GnuTLS: 3.8.5
libnotmuch: 5.6.0
PCRE2: 10.43 2024-02-16
storage: kyotocabinet, lmdb
compression: zlib

Configure options: --prefix=/usr --docdir=/usr/share/doc/packages/neomutt --with-mailpath=/var/mail --kyotocabinet --lua --lmdb --gnutls --gpgme --notmuch --sasl --gss --idn2 --mixmaster --pcre2 --zlib

Compilation CFLAGS: -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -fno-delete-null-pointer-checks -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED -I/usr/include/lua5.4 -I/usr/include -I/usr/include -DNCURSES_WIDECHAR -I/usr/include -I/usr/include/p11-kit-1 -I/usr/include -O2

Compile options:
  -autocrypt +fcntl -flock -fmemopen +futimens +getaddrinfo +gnutls +gpgme
  -gsasl +gss +hcache -homespool +idn +inotify -locales_hack +lua +mixmaster
  +nls +notmuch -openssl +pcre2 +pgp +sasl +smime -sqlite +truecolor

MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

[flatcap]

Looks like I tidied up the date logic a bit too much. Sorry.

Please can you give branch [devel/padding] a try.

Thanks

---

I've changed the rules so that:

• Plain: %d means this day (since midnight, local time)
• Number: %0d means this day (since midnight, local time)
• Number: %1d means in the last whole Day (24 hours)
• Number: %3d means in the last 3 Days (72 hours)

Now I need to create some tests and clarify the docs.

---

NeoMutt running in three timezones: Los Angeles, London, Tokyo.
Each has a different view of which emails arrived "today".

[FilippoBonazziSUSE]

No worries. Yep, that branch fixes the issue, thanks for the extremely quick turnaround.

If I may make a suggestion, maybe you could leave the semantics of the %Nd variable to mean "N days since midnight local time" for any number N (with the default %d == %0d), and introduce a separate %ND variable to mean "N increments of 24 hours" (probably with the default %D == %1D in this case). The two definitions of "day" are distinct and have separate uses, so it could be useful to have both available.

If you think that would be too much, the current solution fixes the bug and works for me anyway.

[flatcap]

Great!

Thanks for the suggestions, I'll have a think (about how much more that'll be :-)

[FilippoBonazziSUSE]

Thinking about it for like another 30 seconds, you already have the %H variable, so adding a second variable %D that just multiplies that by 24 is kind of pointless. So probably %Nd could just be "N days since midnight local time" and a user could specify %NH with N = 24*x to go from hours to days ago.