PERF: Construction of a DatetimeIndex from a list of Timestamp with timezone
State: closed

- [ ] closes #49048 (Replace xxxx with the GitHub issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

trying to use https://peps.python.org/pep-0508/#environment-markers, let's see if this works

Labels:
name: Build
description: Library building on various platforms

Comments:
I'm on board in principle, dont know enough about pep508 to offer an informed opinion
@MarcoGorelli IIUC you added a warning in timezones.pyx to address the associated issue(s).  do you want to do this in addition to that?
> @MarcoGorelli IIUC you added a warning in timezones.pyx to address the associated issue(s). do you want to do this in addition to that?

I don't think I did, no
tzdata is versioned as `2022.1`, `2022.2`, ... on PyPI, but `2022a`, `2022b` on conda-forge 🤦 

I can't see how to specify a minimum for both, but putting `2022.1` and then installing that dependency from PyPI seems to work

But I'm worried that if someone has already installed `tzdata2022a` from conda and then also installs `tzdata2022.1` from PyPI then they'll get issues from the conflict. Or is this a non-issue?

I'm tempted to close, contact the tzdata conda-forge people and ask them to follow the same versioning as the PyPI package, and then specify a minimum which works for both

Removing from the 2.0.0 milestone anyway, this probably isn't something worth backporting (esp. if we're not sure about it)
> tzdata is versioned as `2022.1`, `2022.2`, ... on PyPI, but `2022a`, `2022b` on conda-forge 🤦
> 
> I can't see how to specify a minimum for both, but putting `2022.1` and then installing that dependency from PyPI seems to work
> 
> But I'm worried that if someone has already installed `tzdata2022a` from conda and then also installs `tzdata2022.1` from PyPI then they'll get issues from the conflict. Or is this a non-issue?
> 
> I'm tempted to close, contact the tzdata conda-forge people and ask them to follow the same versioning as the PyPI package, and then specify a minimum which works for both
> 
> Removing from the 2.0.0 milestone anyway, this probably isn't something worth backporting (esp. if we're not sure about it)

This doesn't matter right, as long conda uses the ``run`` dependencies in meta.yaml right?
(We would specify conda tzdata there, and pypi tzdata in setup.cfg)
https://github.com/conda-forge/pandas-feedstock/blob/162d4a7ab02226d308202a7efe194db661aa43e8/recipe/meta.yaml#L35-L39

I don't think it is good practice for people to be installing some of their dependencies using conda and some using pip.
cool, I've gone with 2022.1 then, the conda recipe yaml file can specify 2022a

CI seems to be working fine now
reckon we can get this in for the next release candidate?
I tried this out in a fresh virtual environment on Windows, and tzdata got installed fine: here's my complete unedited traceback https://pastebin.com/JpuCz8PY
Thanks @MarcoGorelli 
Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
git checkout 2.0.x
git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
git cherry-pick -x -m1 3ea17805b072d575d1f55f50fe0027d0fdb9b985
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
git commit -am 'Backport PR #51247: PERF: Construction of a DatetimeIndex from a list of Timestamp with timezone'
```

4. Push to a named branch:

```
git push YOURFORK 2.0.x:auto-backport-of-pr-51247-on-2.0.x
```

5. Create a PR against branch 2.0.x, I would have named this PR:

> "Backport PR #51247 on branch 2.0.x (PERF: Construction of a DatetimeIndex from a list of Timestamp with timezone)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                
@MarcoGorelli could you do the backport?
yup, thanks! guess this didn't make the rc then 😄 oh well