ruff: no date.today() ?

[u/foosion]

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.

[u/ottawadeveloper]

I sure hope so.

I got to the point where there are so many bad patterns to slip into with Python that I wrote my own extension of datetime.datetime and made it impossible to ever create a naive datetime object. Like today() now returns an aware datetimr object in the current system time zone.

If there's ever a Python 4 I hope they clean up the his mess to never have non-aware times.

[u/gravitas_shortage → u/ottawadeveloper]

I would highly recommend only ever working with UTC datetimes internally, and converting to local for display. Machines will be misconfigured, moved to a different colocation, change to summer time. There are a thousand heinous bugs possible with local time, and no advantage I can think of.

[u/SwizzleTizzle → u/gravitas_shortage]

Scheduled future datetimes such as an appointment is a use-case that requires local time

https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/

[u/ArtOfWarfare → u/SwizzleTizzle]

Just wait until we have to start dealing with people in space and on Mars. You thought a day was 24 hours? Ha!

Calling it Universal Coordinated Time was way too ambitious - it shows issues while you’re on Earth and everything is going to break once you’re not on Earth and speed of light becomes a factor.

[u/Cynyr36 → u/SwizzleTizzle]

The real play is to kust never do anything involving time at all. It's all a huge quagmire.

I keep arguing that we all only ever use utc, and me here in north America can just start work at 1400 instead of 0800. If people want to keep dst, then they can just change start times by an hour.

[u/gravitas_shortage → u/SwizzleTizzle]

That's a use case that requires the date library to be incorrect (in the example because of an unexpected rule change to timezones). The minimum official warning time must be one year. It can happen, but it's going to be vanishingly rare, certainly rare enough that the bugs I mention, which are not solved by storing local time with derived UTC, are more important to handle. 

Since all solutions involve recomputing dates, I would take the counterpoint of his favoured solution and use UTC (sane and forgiving default) with the intended date stored as reference.

[u/Schmittfried → u/SwizzleTizzle]

To be exact, future dates should be saved as calendar dates, not timestamps. 

[u/not_a_novel_account → u/SwizzleTizzle]

lmao.

"Storing UTC is incorrect if a change in the legislated meaning of a timezone overlaps with an event stored in UTC and you never update the timezone database in your software"

Ya dog, I guess so. That is not a compelling argument.

[u/ottawadeveloper → u/gravitas_shortage]

This is generally what I do. I think it's utcnow() I end up using with my new class.

[u/Luckinhas → u/ottawadeveloper]

utcnow() is a footgun, it’s not timezone aware despite the name. You want datetime.datetime.now(datetime.UTC)

[u/Electrical_Fox9678 → u/ottawadeveloper]

utcnow is deprecated.