neomutt / neomutt

✉️ Teaching an Old Dog New Tricks -- IRC: #neomutt on irc.libera.chat
https://neomutt.org/
GNU General Public License v2.0
3.27k stars 309 forks source link

Test suite seems to expect TZ=UTC #2100

Closed scy closed 4 years ago

scy commented 4 years ago

Expected Behaviour

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"

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.

scy commented 4 years ago

Thanks for the fast reaction! Can confirm that 26a6b07c728aa88414057cff257cdebfd2967907 fixes the tests for me.