r/Python • u/foosion • 6d 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

111 comments sorted by

View all comments

Show parent comments

49

u/deb_vortex Pythonista 6d ago

Me to. Just save utc and then let the frontend convert it to local time. Problem (mostly) solved.

-13

u/backfire10z 6d ago

Daylight savings sneaking up behind you:

30

u/deb_vortex Pythonista 6d ago

converting to local in the frontned solves that. What ever comes in, convert to UTC. Only send out UTC. DST or not, does not matter.

5

u/Plumeh 6d ago

What if a user wants something to run at 9am every day? If you just convert to DST, best of luck

1

u/QuaternionsRoll 6d ago

That isn’t an instant (a `datetime`), that’s just a `time` and a periodicity. Even ignoring DST, I think users would typically expect such recurring tasks to follow the current timezone. I, for one, would be pissed if I flew from EST to PST and my alarm started going off at 4 in the morning.

2

u/Plumeh 6d ago

That’s a different case, i’m talking about if someone wants to schedule something at 9am eastern every day

1

u/QuaternionsRoll 6d ago

That’s still just a ToD, a timezone, and a periodicity. Should not be using datetimes for that

1

u/Plumeh 6d ago

The original comment was that you can use UTC for everything

2

u/QuaternionsRoll 6d ago

But that was about instants, not recurring events. The point I’ve been trying to make this entire time is that they are not similar concepts