fix: move expensive TimezoneFinder call out of top level.

[jdangerx]

Overview

Just noticed this while chatting about our import time with @cmgosnell.

What problem does this address?

import pudl takes many seconds (like 5-10). Most of this comes from various different libraries we use (sklearn, pandas, dagster, mlflow, etc.) but 0.3 comes from importing pudl.transform.eia.

What did you change?

Moved the instantiation of a timezonefinder.TimezoneFinder closer to its call site - this won't get called for each row, which is good, and it also won't get called at import time, which is also good.

Documentation

Make sure to update relevant aspects of the documentation.

Tasks

Preview Give feedback

1. Update the release notes: reference the PR and related issues.
2. Update relevant Data Source jinja templates (see docs/data_sources/templates).
3. Update relevant table or source description metadata (see src/metadata).
4. Review and update any other aspects of the documentation that might be affected by this PR.

Testing

How did you make sure this worked? How can a reviewer verify this?

haven't yet!

To-do list

Preview Give feedback

1. If updating analyses or data processing functions: make sure to update or write data validation tests (e.g. test_minmax_rows()).
2. Run make pytest-coverage locally to ensure that the merge queue will accept your PR.
3. Review the PR yourself and call out any questions or issues you have.
4. For minor ETL changes or data additions, once make pytest-coverage passes, make sure you have a fresh full PUDL DB downloaded locally, materialize new/changed assets and all their downstream assets and run relevant data validation tests using pytest and --live-dbs.
5. For bigger ETL or data changes run the full ETL locally and then run the data validations using make pytest-validate.
6. Alternatively, run the build-deploy-pudl GitHub Action manually.

[zaneselvans]

Huh, looks like this broke something in the auto-generated API docs.