It depends on what, exactly, you want. time.localtime() will give you a value in the system's configured #timezone. time.gmtime() will give you #UTC. The difference between those will tell you the current local time's offset from UTC.
If you want the name of the configured timezone, on many Unix-type systems, you can read /etc/timezone to get it.
If you want more specific info about a timezone, you can add an external dependency which includes (or provides access to a system-provided) database of timezone info. This stuff changes often, and is decided politically rather than technically, so it's a moving target and the #Python #stdlib doesn't try to include it. `pytz` is one such package with a fairly complete database.
And you can easily override any of these in a test framework. Using unittest.mock.MagicMock(), for example, lets you override any of the above with whatever value you want those functions to return.
I'm deep into rolling forward my long-term #Django project from the 3.2 LTS. The target is to get all the way to 4.2.9 LTS before next weekend.
I've already successfully worked through several utility dependency problems.
Now for the biggie: moving from #pytz to #zoneinfo: https://docs.djangoproject.com/en/5.0/releases/4.0/
Currently, this looks rather daunting...
Today's exercise in vain: I've made a new patch to make #Python #pytz #Gentoo package use system zoneinfo files instead of installing a second copy of the database.
The idea is roughly inspired by the #Fedora patch, with allzones() function based on upstream gen_tzinfo.py. Unlike Fedora, we also do initial stripping via sed, to reduce it by ~600 lines.
@hroncok, interested? ;-)
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=17864cf886299bb86752cf231abdfc9bc5b0d552
C.
Richard Brockie
Michał Górny 