Re: tests/misc/date-debug: fails with latest timezone

[Pádraig Brady]

On 09/03/17 17:26, Bernhard Voelker wrote:
> I'm seeing this failure on the openSUSE build server:
> 
> [  513s] FAIL: tests/misc/date-debug
> [  513s] ===========================
> ...
> [  513s] + TZ=America/Lima
> [  513s] + date --debug -d @1
> [  513s] + compare exp3 out3
> [  513s] + compare_dev_null_ exp3 out3
> [  513s] + test 2 = 2
> [  513s] + test xexp3 = x/dev/null
> [  513s] + test xout3 = x/dev/null
> [  513s] + return 2
> [  513s] + case $? in
> [  513s] + compare_ exp3 out3
> [  513s] + diff -u exp3 out3
> [  513s] --- exp3     2017-03-10 00:17:23.843634722 +0000
> [  513s] +++ out3     2017-03-10 00:17:23.847634722 +0000
> [  513s] @@ -4,4 +4,4 @@
> [  513s]  date: final: 1.000000000 (epoch-seconds)
> [  513s]  date: final: (Y-M-D) 1970-01-01 00:00:01 (UTC0)
> [  513s]  date: final: (Y-M-D) 1969-12-31 19:00:01 (output timezone TZ=-05:00)
> [  513s] -Wed Dec 31 19:00:01 PET 1969
> [  513s] +Wed Dec 31 19:00:01 -05 1969
> [  513s] + fail=1
> 
> This is due to changing the timezone abbreviations of South America
> to numerical format [1] in brand new 'timezone-2017a':
> 
>   https://github.com/eggert/tz/commit/c9e6ef07cc
> 
> It seems we cannot rely on the timezone abbreviations any longer
> in our tests.  For now, I suggest to work around the current
> FP for the "America/Lima" test.
> 
> WDYT?

Well it's less broken with that :)
A more general fix abstracting away all abbreviated timezones would be good.
This doesn't show too many:

  $ LC_ALL=C git grep '[A-Z]\{3\} [12][016-9]\{3\}' tests
  tests/misc/date-debug.sh:Thu Dec 13 07:30:00 CST 1990
  tests/misc/date-debug.sh:Wed Dec 31 19:00:01 PET 1969
  tests/misc/date-debug.sh:Sat Oct  1 00:00:00 UTC 2016
  tests/misc/date-debug.sh:Sun Dec 11 00:00:00 EET 2011
  tests/misc/date-debug.sh:Sat Jun 11 00:00:00 EEST 2011
  tests/misc/date-debug.sh:Mon Apr 11 22:59:00 UTC 2011
  tests/misc/date.pl:      {OUT => 'Wed Dec 31 21:00:00 PST 1969'},

Note that doesn't search for numeric TZ output,
and even that may change sometimes, so I'm not sure
how best to abstract away completely.
At least moving the above to numeric would be good.

thanks,
Pádraig