-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DTZ005 false postitive for tz=None
#10251
Comments
I think this is arguably a true positive, since |
I think it’s arguable. No arguments could be a mistake (and is a common one). Explicitly passing None is acknowledging that you actually want None. In my case I want to use UTC everywhere except in a helper script. But yes at least an error message tweak would be nice. |
Yeah I also view it as borderline. I could definitely be convinced to ignore it. May need more opinions. @AlexWaygood, what do you think? |
It seems like we're following what the original flake8 rule does here, which is explicitly going out of its way to make sure that calls are still flagged when I... am sort-of inclined to leave this rule as it is, though. It's simple to explain currently: "aware datetimes are good; naive datetimes are bad". Keeping a rule simple to explain to users and easy to describe in documentation is valuable. Moreover, if we changed the behaviour here, it's possible people who don't understand the rationale behind the rule might think that they're "fixing" the issue by passing I feel like if you're working in a domain where you don't need aware timezones, you can probably just not enable this rule on your project. And if you have a specific script in a larger project where it's just that script that doesn't need aware timezones, you can probably just put |
That's a fair point, I hadn't thought of that. I guess the other recommendation is to do: datetime.now(tz=timezone.utc).astimezone() Which I think gives you the local timezone, although it's not as simple as Either way, whatever you choose is fine by my, I just wanted to bring it to attention. |
I think we should just improve the rule documentation and recommendation here |
ruff 0.1.9
The text was updated successfully, but these errors were encountered: