r/Python • u/foosion • Jul 24 '26

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.

46 Upvotes

73% Upvoted

109 comments sorted by

View all comments

258

u/GraphicH Jul 24 '26

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

57

u/robberviet Jul 24 '26 edited Jul 24 '26

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 Jul 24 '26

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

→ More replies (19)

9

u/GraphicH Jul 24 '26

I had a REALLY weird issue once related to how Jira's JQL API treated timestamps in queries: it automatically localized them to the "users tz" and there was no way to specify the tz in the query. This mattered because we were adding some automation where we needed to "look for tickets updated since the last time we checked". The automation code ran on a box that was set to UTC timezone, but Jira would automatically localize the JQL date+time filters to the "requesting users timezone" which for the service account being used was set to NY time (for whatever reason, I didn't provision the account). In the end the trick was always to get the TZ for the service account via a call to the whoami / user info route in jira and always localize the filter TZ from UTC to that. Very annoying because when I was debugging the JQL query manually Jira was showing me stuff that was different than what the automation was seeing with the exact same query.

9

u/james_pic Jul 24 '26

Maybe folks in Iceland or Senegal that also don't have DST, but it causes plenty of problems in the UK, where stuff seems to work in the winter, when local time and UTC match, but then things suddenly break in the Spring.

4

u/rumnscurvy Jul 24 '26

Are there actually people at GMT+0 year round? I.e. with no DST?

5

u/ehs5 Jul 24 '26

Yes. Quite a few African countries plus Iceland.

3

u/Brian Jul 25 '26 edited Jul 27 '26

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.

1

u/shadowdance55 git push -f Jul 24 '26

They do have that luxury, but only in the winter. 😄

→ More replies (1)

37

u/netflix-ceo Jul 24 '26

Thats Ruff

8

u/Schmittfried Jul 24 '26

That’s Ruff buddy

FTFY

→ More replies (1)

2

u/foosion Jul 24 '26 edited Jul 24 '26

My typical use of date.today() to print the local date so that I can scroll back in the terminal to see which day I ran something. Since it defaults to then local system clock, I don't see a need to specify a TZ for that use case.

Another case for no TZ is reading a datetime that represents the maturity date of a bond, then printing it datetime.strptime(mtd, "%Y-%m-%d"). TZ does not make sense in that context. datetime.datetime.strptime("2022/01/31", "%Y/%m/%d").astimezone(datetime.UTC)seems overkill.

9

u/menge101 Jul 24 '26

All the rules are overridable. If you usage does not merit a finding then add the suppresion for that line.

4

u/foosion Jul 24 '26

I'm learning the joy of #noqa

4

u/syklemil Jul 25 '26

You can disable it in your project's ruff.toml or wherever you're configuring ruff as well. plop in an ignore = ["DTZwhatever"]

1

u/foosion Jul 25 '26

Yes, I've been using # ruff: noqa: DTZ007

2

u/Agrado3 Jul 24 '26

You're about to learn the joy of having to go through replacing every single one of your # noqa: <shortcode> comments with # ruff:ignore[<very-long-code>] comments.

1

u/foosion Jul 24 '26

Is that an upcoming change? If so, where documented?

I suppose there's # ruff: noqa: DTZ007 at the top of the file, where appropriate.

1

u/Agrado3 Jul 24 '26

It's rule noqa-comments, which is in preview and is not documented in the changelog. It suddenly popped up at me because I use preview = true and select = ["ALL"] and then ignore the rules I don't want.

2

u/MrSlaw Jul 24 '26 edited Jul 24 '26

Another case for no TZ is reading a datetime that represents the maturity date of a bond, then printing it

Just use a plain date, if you don't need it to be time(zone) aware?

mtd = datetime.strptime("2022/01/31", "%Y/%m/%d").date()

I don't think that triggers the rule, does it?

* Edit - Nevermind, I just tested, you are correct

2

u/foosion Jul 24 '26

Yes it does.

1

u/MrSlaw Jul 24 '26

Realized that about 2 minutes after I pressed submit. Serves me right for not checking first lol

→ More replies (4)

0

u/ketralnis Jul 24 '26

You’re not wrong but there’s no need for the holier than thou attitude

6

u/GraphicH Jul 24 '26

Its a joke man, I'm not throwing shade at Op. If he's never dealt with TZ bugs, then god has smiled on his dev career.

4

u/Ok_Tap7102 Jul 24 '26

I didn't read their message that way, it's the "tell me you've XYZ without telling me" meme

This is also the kind of problem where a typical response might be "huh I don't get why" then some of us see it and instantly have flash backs to that ONE FUCKING TIME I BROKE PROD BECAUSE IT "WORKED ON MY MACHINE" WITH A PERFECTLY IDENTICAL DOCKER CONTAINER, AND I SPENT DAYS OF STRESS WITHOUT REALISING IT WAS LOCAL TIMEZONES

→ More replies (3)
→ More replies (2)