PLONE_RESTAPI_DX_FIXTURE errors in Windows because of time.tzset()

[ewohnlich]

I wrote some tests for my package using the PLONE_RESTAPI_DX_FIXTURE, but these fail because time.tzset() is not available in Windows. This is used plone.restapi.testing DateTimeFixture

To Reproduce

testing.py:

from plone.restapi.testing import PLONE_RESTAPI_DX_FIXTURE
RESTAPI_TESTING = FunctionalTesting(
    bases=(FIXTURE, WSGI_SERVER_FIXTURE, PLONE_RESTAPI_DX_FIXTURE),
    name="EntrezSiteLayer:RestAPITesting",
)

conftest(s):

globals().update(
    fixtures_factory((
        (FUNCTIONAL_TESTING, "functional"),
        (INTEGRATION_TESTING, "integration"),
        (RESTAPI_TESTING, "restapi"),
    ))
)

...

@pytest.fixture
def api_session(portal):
    session = RelativeSession(portal.absolute_url())

    session.headers.update({"Accept": "application/json"})
    session.auth = (SITE_OWNER_NAME, SITE_OWNER_PASSWORD)
    return session

test:

def test_api_empty(self, api_session):
        response = api_session.get(
            url="/@publications/search",
        ).json()
        assert response["metadata"]["count"] == 0
        assert response["publications"] == []

Error

request = <SubRequest 'zope_layer_class_plone_restapi_testing_DATE_TIME_FIXTURE_2530063177104' for <Function test_api_empty>>, layer = <Layer 'plone.restapi.testing.DateTimeFixture'>

    def class_fixture(request, layer):
        state = request.session.zopelayer_state
        if layer not in state.current:
>           setup_layer(layer, request)

.\.venv\Lib\site-packages\zope\pytestlayer\fixture.py:69: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
.\.venv\Lib\site-packages\zope\pytestlayer\fixture.py:40: in setup_layer
    layer.setUp()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <Layer 'plone.restapi.testing.DateTimeFixture'>

    def setUp(self):
        tz = "UTC"
        os.environ["TZ"] = tz
>       time.tzset()
        ^^^^^^^^^^
E       AttributeError: module 'time' has no attribute 'tzset'

.\.venv\Lib\site-packages\plone\restapi\testing.py:80: AttributeError

tzset is not available in Windows. My tests pass with this commented out. I am not sure of the intended behavior here, but if it can't be os independent would it be possible to make this conditional on os.name != 'nt'?

Additional details

Plone: 6.2.0
plone.restapi: 10.0.0

[stevepiercy]

If I understand correctly, to preserve the test for Windows, you'd need to replace tzset() with something else such as zoneinfo from the standard library.

from datetime import datetime
from zoneinfo import ZoneInfo

utc_tz = ZoneInfo("UTC")

now_utc = datetime.now(utc_tz)

print(f"Current time in UTC: {now_utc.strftime('%Y-%m-%d %H:%M:%S %Z')}")

icalendar's tests might be a source to avoid reinventing the wheel.

There's a @pytest.mark.skipif in icalendar that could be used as a last resort. See https://github.com/search?q=repo%3Acollective%2Ficalendar+windows+path%3A%2F%5Esrc%5C%2Ficalendar%5C%2F%2F&type=code.

HTH.

[davisagli]

@stevepiercy zoneinfo doesn't serve the same purpose as time.tzset(). From what I can see, time.tzset() uses the POSIX tzset syscall to update some variables that affect how times are converted to "local" time in cases where a specific timezone isn't specified. It's used here because the rest of the Plone codebase hasn't been updated to use zoneinfo yet, and we want our tests to use a consistent timezone regardless of how various Plone libraries look it up.

@ewohnlich It makes sense to me to make this conditional on the OS. Even if there are remaining issues with time handling on Windows, we'd like to see those rather than this error. Would you mind making a PR?

[ewohnlich]

Sure, I'll make a PR. What would be better is if there is a test that can be shown to fail without this, on Windows, and then find a solution. But that probably depends on the local time and would be tricky to test...