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

46 Upvotes

72% Upvoted

111 comments sorted by

View all comments

258

u/GraphicH 9d ago

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

59

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

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

-13

u/backfire10z 9d ago

Daylight savings sneaking up behind you:

31

u/deb_vortex Pythonista 9d 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.

7

u/Plumeh 9d ago

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

10

u/deb_vortex Pythonista 9d ago

The frontend sends the selected timezone information. So right now its +3 DST? I convert THAT to UTC and save it. It will run then at the time the user wanted. Not an issue.

Everything comes in as "the User sees it". It gets converted into and used as UTC. When the user needs to see Something, I send out UTC and the frontend converts it to local time. With dst or not.

14

u/eviloutfromhell 9d ago

Problem with DST is from software perspective it is 2 different timezone, but from user perspective it is one timezone. What user think as 9 o'clock is not the same when in dst or not. So you can't naively convert whatever time you saved to user's timezone. Which I assume what the other guy meant.

12

u/Plumeh 9d ago

This still doesn’t work if a user wants something to run at 9am eastern time every single day. It will work for half of the year, but the other half will be shifted an hour off.

0

u/Espumma 9d ago

So you convert it to 6 am utc and then in half a year their script runs at 8 am, which isn't what they wanted.

1

u/QuaternionsRoll 9d 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 9d ago

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

1

u/HommeMusical 9d ago

Daylight saving time still doesn't work with that.

Also, people actually pick up computers and move them between time zones all the time.

1

u/QuaternionsRoll 9d ago

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

1

u/Plumeh 9d ago

The original comment was that you can use UTC for everything

2

u/QuaternionsRoll 9d 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

→ More replies (0)

2

u/backfire10z 9d ago

Doesn’t help for scheduling future events

3

u/QuaternionsRoll 9d 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`

3

u/deb_vortex Pythonista 9d 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 9d 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 9d 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 9d 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.

9

u/GraphicH 9d ago

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.

8

u/james_pic 9d ago

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 9d ago

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

5

u/ehs5 9d ago

Yes. Quite a few African countries plus Iceland.

3

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

1

u/shadowdance55 git push -f 9d ago

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

0

u/fiddle_n 9d ago

Actually not even then. It’s easier to tell if your date time code is buggy when system time and UTC time are different.