Fix tz to UTC in test_time test

[StanFromIreland]

Currently on DST, this causes:

======================================================================
FAIL: test_localtime_timezone (test.test_time.TestPytime.test_localtime_timezone)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stan/PycharmProjects/cpython/Lib/test/test_time.py", line 772, in test_localtime_timezone
    self.assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst])
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 3600 != 0

----------------------------------------------------------------------
Ran 63 tests in 2.938s

FAILED (failures=1, skipped=3)
test test_time failed
0:00:02 load avg: 1.87 [1/1/1] test_time failed (1 failure)

== Tests result: FAILURE ==

1 test failed:
    test_time

Total duration: 3.0 sec
Total tests: run=63 failures=1 skipped=3
Total test files: run=1/1 failed=1
Result: FAILURE

[serhiy-storchaka]

It looks to me that the purpose of the test is to run on non-UTC timezone. It does not make sense to run it on UTC.

[StanFromIreland]

It is buggy on most timezones. See https://buildbot.python.org/#/builders/1678/builds/17 as an example (uses IST). It is not an inherently non-UTC test, I can freeze it to something else if there is another one guaranteed to work.

[pganssle]

Shouldn't we solve this by making the test actually test that the desired behavior applies across all zones?

[StanFromIreland]

solve this

Solving this for all time zones is unlikely.

As you said earlier:

So now it seems that there's no way to determine what the correct timezone offset and name are based on isdst.

I was looking into this over the last few days and was unable to find a nice solution either.

[serhiy-storchaka]

This test was added in 2012 and was not changed since. If it fails, there is something wrong either with our code, or with platform. Please open an issue and provide as much details as possible. What platform, on what timezone the test fails.

[StanFromIreland]

The issue (by Paul) has been open for a while #83985

[pganssle]

I think that this issue only comes up in zones with negative DST, and it's hitting into a real bug. Fixing the test to UTC makes it seem like this test — which doesn't really do much in UTC, mind you — is not intended to work in other zones, which is the opposite of the truth.

This is the kind of thing that we would use xfail for if we were able to use pytest, though it's a bit tricky to define exactly where it fails. I think there are a couple of options here:

1. Fix the underlying bug in some way
2. Do something like xfail where you check for known failure conditions and affirmatively assert that the test is wrong (with a message to the effect that if that ever starts failing, we we should simply remove the "this test fails" assertion). This can probably be done with zoneinfo if you can figure out the system's TZID (assuming it has one), or possibly with datetime, if datetime.astimezone() sets the result of dst() to the correct thing (you just need to detect negative DST). Kinda tricky.
3. Parameterize this test over a variety of fixed zones and times, and do the xfail thing for the ones where you know it is failing.

If we have a good way to parameterize over locale and to run these things with fixed times (a la freezegun), then I think option 3 is way better than option 2. It's a bit of a problem that this test will only fail during part of the year if run in a specific locale. Even if we fix the bug, ideally we'd have tests that always succeed or fail no matter what locale the test suite is run in.

(I realize I should probably know if we have a way to freeze time or parameterize over locales, but as you may have noticed by the delay in my responses to most things, my free time is extremely limited these days and it's been a while since I looked into the finer points of what's available in our test supports).