Bazel test messing up system time

Description of the problem / feature request:

When using python (tested with 3.6.8 and 2.7.15+), running a test versus a binary yield different system times when run using bazel (bazel run <target>).

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Here is the BUILD file:

py_test(
    name = "date_test",
    srcs = [
        "date_test.py",
    ],
    python_version = 'PY3',
)
py_binary(
    name = "date_print",
    srcs = [
        "date_print.py",
    ],
    python_version = 'PY3',
)

Here is the test code:

import datetime
import unittest
class DateTest(unittest.TestCase):
  def test_date(self):
    now = datetime.datetime.now()
    print(now)
if __name__ == '__main__':
  unittest.main()

Here is the binary code:

import datetime
now = datetime.datetime.now()
print(now)

If I run the code directly without bazel:

nic@quasar:~/dev/bazel_test_date$ python3 date_print.py && python3 date_test.py
2019-10-07 23:49:03.940868
2019-10-07 23:49:04.217462

Everything is good.

If I manually run the bazel generated files:

nic@quasar:~/dev/bazel_test_date$ bazel-bin/date_print && bazel-bin/date_test
2019-10-07 23:49:18.177063
2019-10-07 23:49:18.715331

Everything is good.

However, if I run it under using bazel, the problem is shown:

nic@quasar:~/dev/bazel_test_date$ bazel run :date_print && bazel run :date_test
2019-10-07 23:50:01.700563
2019-10-08 06:50:03.489103

The dates are WAY off. The date_print is right, the date_test is 1/4 day in the future.

What operating system are you running Bazel on?

Ubuntu 18.04.3 LTS Python 3.6.8 and Python 2.7.15+

What’s the output of bazel info release?

release 0.29.0

[akirchhoff-modular]

You can check it in two ways:

1. Change your test code that runs inside of Bazel to explicitly set a non-UTC time zone before beginning the test. Then it can match your unmodified outside-of-Bazel code.
2. Modify your outside-of-Bazel code to set the time zone to UTC. Then it can match Bazel’s test environment.

I think you are right that using the system time at all is not hermetic, but complete hermeticity is difficult to achieve. That does not mean it is not worth striving for, so even if it is not perfect, Bazel tries to control what it can. The time zone is easy to control for, so Bazel does so.

[nicmcd]

I’m not saying give up. I’m trying to say that there are things we can reasonably set up for hermetic tests, and there are things that we can’t and shouldn’t. For example, having a frozen clock might be great for some tests, but it would completely remove the ability to test code that has timeouts. Why should users have to fight this?

My opinion is that users should not have to guess about what Bazel and the libraries being tested are doing underneath the hood. The reason I don’t like the TZ=UTC setting is that I just don’t know when that gets paid attention to. I don’t want to have to fight to undo Bazel’s poor attempt at hermeticity. I’d rather fight to guarantee hermeticity. For example, if I have a hard coded test result that is based on UTC, then I’d better guarantee that my test environment believes it is UTC. If not, then I’d make my expected result according to whatever timezone my machine thinks it is.