Ruff is warning about date.today() and suggesting a timezone-aware alternative. Is date.today() deprecated, or is this just a linting preference?
Some of my code handles financial dates for Excel, including bond maturity dates, where a timezone doesn't seem relevant.
It's the Ruff rule DTZ011, not a deprecation of date.today(). The concern is that today depends on the system's local timezone, which may not be the timezone your application means.
If you need today's date in a particular place, use datetime.now(ZoneInfo("America/New_York")).date(), for example. The result is still a date, not a timezone-aware datetime. The timezone just makes the choice of calendar day explicit.
A bond maturity date is a calendar date, not an instant that needs converting to UTC. If you're parsing or storing that date, adding a timezone can make the model more confusing rather than more accurate.
The separate question is how you decide what counts as today when comparing it with the maturity date. That might be a business timezone, or it might intentionally be the machine's local date.
For logging a date in a local terminal, date.today() can be exactly what you want. It uses the system's local date, so the warning may not be useful there. Suppressing the rule at those call sites is reasonable if that behavior is intentional.
The warning is valuable in services that run on different machines. A local timezone setting can change what day the code sees, and those bugs can be unpleasant to track down.
For actual timestamps, keeping them in UTC internally and converting for display is a useful default. For a business date, though, choose the timezone that defines the business day before extracting the date. UTC isn't automatically the right answer for that.
Answers are reviewed before publication.
Brelva+8k:
That distinction matters around midnight, when two timezones can be on different calendar dates.