When building 20191207 from source, I expected the test suite to succeed.
Actual Behaviour
Test test_mutt_date_is_day_name... [ OK ]
Test test_mutt_date_localtime... [ FAILED ]
Case December, 2000:
mutt_date_localtime.c:36: Check tm.tm_hour == 12... failed
Case June, 2000:
mutt_date_localtime.c:49: Check (tm.tm_hour == 12) || (tm.tm_hour == 11)... failed
hour = 13
Test test_mutt_date_localtime_format... [ FAILED ]
mutt_date_localtime_format.c:49: Check result == true... failed
Test test_mutt_date_local_tz... [ OK ]
Test test_mutt_date_make_date... [ OK ]
Test test_mutt_date_make_imap... [ FAILED ]
mutt_date_make_imap.c:43: Check result == true... failed
Test test_mutt_date_make_time... [ FAILED ]
Case {0,0,0,1,0,10000,0} = 9223372036854775807:
mutt_date_make_time.c:74: Check result == 946684800... failed
Test test_mutt_date_make_tls... [ OK ]
Test test_mutt_date_normalize_time... [ OK ]
Steps to Reproduce
On my machine, env TZ=Europe/Berlin make test is enough to result in the failure, while all tests are green when running env TZ=UTC make test. But my machine is Ubuntu Bionic running under the Windows Subsystem for Linux (WSL), and WSL is a bit strange when it comes to timezones, so take this information with a grain of salt. If you can’t reproduce this locally, I can try spinning up a VPS somewhere to build a test case.
However, there’s also Debian #948895 that seems to be the same issue.
NeoMutt Version
I’m trying to build NeoMutt from source.
NeoMutt 20191207
Copyright (C) 1996-2016 Michael R. Elkins and others.
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 4.4.0-18362-Microsoft (x86_64)
ncurses: ncurses 6.1.20180127 (compiled with 6.1.20180127)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.10.0
libnotmuch: 5.0.0
hcache backends: tokyocabinet
Configure options: --prefix=/opt/neomutt-20191207 --with-mailpath=/var/mail --gpgme --notmuch --with-ui --gnutls --gss --idn --mixmaster --sasl --tokyocabinet
Compilation CFLAGS: -g -O2 -std=c99 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/opt/neomutt-20191207/include -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
-autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens
+getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify
-locales_hack -lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime
-sqlite +start_color +sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/opt/neomutt-20191207/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/opt/neomutt-20191207/etc"
The tests that fail seem to be explicitly about testing conversion between a Unix timestamp and local dates and, as such, will probably need to rely on a certain, fixed timezone to be in effect while they run. However, I can’t find anything in the docs asking me to set my timezone to UTC before running the test suite, nor do the tests seem to set a certain timezone on their own.
Also, maybe I don’t understand the implications, but might I suggest testing “local time” code against dates/times in a timezone different to UTC? That way, the tests would actually simulate a user having a local timezone other than UTC.
Expected Behaviour
When building
20191207
from source, I expected the test suite to succeed.Actual Behaviour
Steps to Reproduce
On my machine,
env TZ=Europe/Berlin make test
is enough to result in the failure, while all tests are green when runningenv TZ=UTC make test
. But my machine is Ubuntu Bionic running under the Windows Subsystem for Linux (WSL), and WSL is a bit strange when it comes to timezones, so take this information with a grain of salt. If you can’t reproduce this locally, I can try spinning up a VPS somewhere to build a test case.However, there’s also Debian #948895 that seems to be the same issue.
NeoMutt Version
I’m trying to build NeoMutt from source.
Extra Info
The Travis build for 20191207 was green. No idea what timezone Travis uses though. However, I’ve noticed that there’s already some strange workaround in
tests/date/mutt_date_localtime.c
.The tests that fail seem to be explicitly about testing conversion between a Unix timestamp and local dates and, as such, will probably need to rely on a certain, fixed timezone to be in effect while they run. However, I can’t find anything in the docs asking me to set my timezone to UTC before running the test suite, nor do the tests seem to set a certain timezone on their own.
Also, maybe I don’t understand the implications, but might I suggest testing “local time” code against dates/times in a timezone different to UTC? That way, the tests would actually simulate a user having a local timezone other than UTC.