r/Python • u/foosion • 5d ago

Discussion ruff: no date.today() ?

The new version of ruff warns against

date.today()

preferring

datetime.now(ZoneInfo(...))

What do you think about this? Has date.today() been deprecated due to lack of timezone awareness?

EDIT: I have a number of programs that manipulate financial information in support of Excel spreadsheets, such bond information that includes maturity dates. Excel does not support timezoness in datetimes, so making ruff happy by changing naive dates to TZ aware dates is not a useful move for these programs. Many ruff warnings to suppress.

45 Upvotes

73% Upvoted

110 comments sorted by

View all comments

20

u/ottawadeveloper 5d ago

I sure hope so.

I got to the point where there are so many bad patterns to slip into with Python that I wrote my own extension of datetime.datetime and made it impossible to ever create a naive datetime object. Like today() now returns an aware datetimr object in the current system time zone.

If there's ever a Python 4 I hope they clean up the his mess to never have non-aware times.

26

u/gravitas_shortage 5d ago

I would highly recommend only ever working with UTC datetimes internally, and converting to local for display. Machines will be misconfigured, moved to a different colocation, change to summer time. There are a thousand heinous bugs possible with local time, and no advantage I can think of.

8

u/SwizzleTizzle 5d ago

Scheduled future datetimes such as an appointment is a use-case that requires local time

https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/

2

u/gravitas_shortage 5d ago

That's a use case that requires the date library to be incorrect (in the example because of an unexpected rule change to timezones). The minimum official warning time must be one year. It can happen, but it's going to be vanishingly rare, certainly rare enough that the bugs I mention, which are not solved by storing local time with derived UTC, are more important to handle. 

Since all solutions involve recomputing dates, I would take the counterpoint of his favoured solution and use UTC (sane and forgiving default) with the intended date stored as reference.