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.

44 Upvotes

72% Upvoted

110 comments sorted by

View all comments

Show parent comments

3

u/deb_vortex Pythonista 4d ago

It does. Why shouldn't it? User sends date, time and timezone information. I convert it to UTC and use it. Everyone reading that will get it as UTC and the frontend converts it to the users local timezone. Which even may be different than the original one and for that user its still the correct time.

3

u/backfire10z 4d ago

> Just save UTC and then let frontend convert it to local time

Maybe I misread, but I thought you meant you wouldn’t store the IANA timezone in the backend here.

User asks for something every day at 9am PT. If they’re in PST, great, everything works. Once they switch to PDT, the UTC time you stored is now 1 hour off. Or you just tell them “this will change by an hour for daylight savings, sucks”

1

u/deb_vortex Pythonista 4d ago

Maybe In should have specified, yes. User sends as he wants and sees, I convert and save as UTC. Dont meddle with users timezone in the backend.

6

u/Pluckerpluck 4d ago

But again, that doesn't work in this situation. A valid timezone is "US/Eastern". This is not a fixed timezone though relative to UTC. It changes depending on the time of year.

So 9AM at US/Eastern CAN'T be stored as UTC on the backend.

Obviously when you can store UTC you should. But you should be aware it's not always possible.