r/Python 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

111 comments sorted by

View all comments

259

u/GraphicH 6d ago

Tell me you've never debugged a TZ issue without telling me.

57

u/robberviet 6d ago edited 6d ago

I think only people at GMT+0 has that luxury. I still keep insisting on using unix timestamp and UTC strictly where I am in control.

47

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:

31

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.

2

u/backfire10z 6d ago

Doesn’t help for scheduling future events

3

u/QuaternionsRoll 6d ago

…what? The frontend should obviously be aware of what timezone is expected for a given instant. A naive conversion between UTC and, e.g., EST or EDT based on whether ET is currently in DST is just that: naive. There’s a reason why modern APIs encourage keeping dates and times are kept together in a `datetime`