This won't work, because the JS ISO format coming from the worker is different than the ISO format Python uses (no Z suffix for UTC timezone) 🤦 So this has to be like it was.

>>> datetime.fromisoformat('2023-01-20T16:20:11.655Z')
ValueError: Invalid isoformat string: '2023-01-20T16:20:11.655Z'

Let's sync on monday and discuss whether we want to use formats with timezone or not. I have exclusively used datetime.utcnow() which does not have timezone included

Let's discuss it mabe we shoule use dateunit as it looks can pase this string.
I'm afraid we can found issue in more places, I just test stringify JSON in JS and it looks same format:

JSON.stringify({'date': new Date('2023-01-20T16:20:11.655Z')})
{"date":"2023-01-20T16:20:11.655Z"}

You could just use env_var.name.lower() here, to get the name of the enum key, without having to do the replace.

Ok, it looks it works. but I have not sure why. Can you explain a little bit, looks that INTEGER_ENV_VARS is List and then int_env_var is just an item of the list, a dummy string.

It's all because of how Enums work in Python:

• ApifyEnvVars is an Enum
• ApifyEnvVars.MEMORY_MBYTES is an Enum member (not the value directly)
• ApifyEnvVars.MEMORY_MBYTES.name is the Enum member name ('MEMORY_MBYTES')
• ApifyEnvVars.MEMORY_MBYTES.value is the Enum member value ('APIFY_MEMORY_MBYTES')
• INTEGER_ENV_VARS is a List of ApifyEnvVars members, not their values directly

It works a bit differently than in TypeScript, where accessing the enum member gives you its value directly, not the whole member object.

The monkeypatch.setenv(int_env_var, ...) should really be monkeypatch.setenv(int_env_var.value), to be completely correct. It works right now because internally the os.environ[int_env_var] will do int_env_var.encode(...) or int_env_var.upper() before setting the env var (depending on whether you're on UNIX or Windows), which returns the enum member value, and it works. (See https://github.com/python/cpython/blob/main/Lib/os.py#L745-L772)