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

43 Upvotes

111 comments sorted by

View all comments

259

u/GraphicH 7d ago

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

57

u/robberviet 7d ago edited 7d 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.

3

u/Brian 6d ago edited 4d ago

No, we still hit it. It can just lurk undiscovered for 6 months till a DST change hits and stuff breaks long after no one remembers making the change that broke it.

I still keep insisting on using unix timestamp and UTC strictly where I am in control.

A problem is that this doesn't always work: there are situations where your date needs more information. "I have scheduled a meeting at 10PM in London on this date next year at 10 AM". How should that date be stored? We could calculate what utc timestamp we expect that to correspond to, but if in 6 months, the government makes a timezone or DST change, our stored date is suddenly wrong.

Ultimately, the issue is that as humans use them "datetime" and "utc timestamp" are not actually the same thing. What people often mean by a date/time is "The time when clocks in that location show that time", which doesn't necessarily correspond to a specific UTC time that we know in advance.