[PATCH] [llvm-ranlib] Take in consideration UTC offset for D-flag.test

[zatrazz]

Summary

The llvm-ar uses localtime to print the object timestamp and it is
subject to UTC offset (daylight for instance). The patch changes
the test to check against output of a 'date' command.

It fixes the D-flag.test failure on some aarch64 and arm bots,
which are situated on GMT with currently BST timezone.

[kristof.beyls]

llvm/test/tools/llvm-ranlib/D-flag.test

13

I wonder if 'date' is available on all platforms that LLVM builds on. For example, is it available on Windows (with GnuWin32 installed, as per the requirements listed at https://llvm.org/docs/GettingStartedVS.html)? http://gnuwin32.sourceforge.net/packages.html doesn't seem to list "date" explicitly?

[arichardson]

I was careful in the test to use TZ=UTC for all commands printing dates and it works fine for me in UTC+1 and in the UK which is currently UTC. Does the bot in question ignore the TZ variable?

[arichardson]

llvm/test/tools/llvm-ranlib/D-flag.test

23

Wouldn't this line also have to change?

[zatrazz]

Updated patch based on previous comments.

[zatrazz]

llvm/test/tools/llvm-ranlib/D-flag.test

13

It is provided by coreutils (http://gnuwin32.sourceforge.net/packages/coreutils.htm).

23

It does and I updated the patch.

[arichardson]

I'm fine with this workaround although I'm very surprised that the test is not working. Especially since deterministic-archive.test and replace-update.test also set TZ to get reproducible output

Do you have access to any of the failing bots? If so what happens there if you change the TZ variable?
I get the following on all systems I have access to when I run something like date && date -u && env TZ=CET date && env TZ=CET date -u && env TZ=BST date && env TZ=BST date -u I get the following output:

Thu  9 Jan 2020 20:18:10 GMT
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 21:18:10 CET
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC

[zatrazz]

In D72449#1812130, @arichardson wrote:

I was careful in the test to use TZ=UTC for all commands printing dates and it works fine for me in UTC+1 and in the UK which is currently UTC. Does the bot in question ignore the TZ variable?

The issue is setting TZ=UTC still might use internal database with UTC offsets. For instance, on the buildbot
that accused the regression, setting TZ=UTC make it use the tz database /usr/share/zoneinfo/UTC. At least
on Linux with glibc one way to actually use UTC without transit changes are to set TZ=":", it won't try to
access either the default '/etc/localtime'. However, I am not sure how portable it is and it might be in fact
an glibc issue (https://sourceware.org/bugzilla/show_bug.cgi?id=24004).

[zatrazz]

In D72449#1812818, @arichardson wrote:

I'm fine with this workaround although I'm very surprised that the test is not working. Especially since deterministic-archive.test and replace-update.test also set TZ to get reproducible output

Do you have access to any of the failing bots? If so what happens there if you change the TZ variable?
I get the following on all systems I have access to when I run something like date && date -u && env TZ=CET date && env TZ=CET date -u && env TZ=BST date && env TZ=BST date -u I get the following output:

Thu  9 Jan 2020 20:18:10 GMT
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 21:18:10 CET
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC

I am not sure now if it was something wrong with the bot tzdata, I reinstalled the tzdata packages
and reconfigured the timezone and now 'TZ=UTC date -d '@0' +%H:%M' does show the expected
00:00.

Indeed, although the workaround shouldn't change the expected result, the issue I am observing
on some machine does not make sense (TZ=UTC date -d '@0' +%H:%M' not showing 00:00).

I will hold this and investigate further.