Add tz argument to date.today()

[lucaswiman]

Feature or enhancement

Add a tz argument to date.today, mirroring the interface of datetime.now.

Pitch

"Today" depends on the time zone, but there are many situations where you may be interested in the current date in other time zones. The most common is probably a server that runs in UTC time, but is used by people around the world.

Example use cases:

• A calendar application where you want to show today's appointments to the end user, in the end-user's time zone.
• Prioritizing records by due date, with records due today prioritized over records that are late.
• Business rules involving when a record is "stale" that depends on a number of days ago relative to a date. This can easily lead to off-by-one errors if you don't specify the time zone.

Currently, these can be implemented with datetime.now(tz=...).date(). While this is not a huge inconvenience, it seems like "today" and "now" both depend on the timezone, so they should both take the same inputs.

Previous discussion

This was discussed in this thread on python-ideas. No one voiced any opposition, and Steven D'Aprano suggested I create an issue here.

Implementation

The python code in datetime.py looks fairly easy to change. Basically add something like:

if tz is not None:
    return datetime.now(tz=tz).date()

That may not be the most performant implementation, though it's guaranteed to pick up any bugfixes to .now(...), which is desirable.

I'm less familiar with the C code. The relevant piece seems to be here, which may be able to work in the same way (calling the .now() code). If anyone has implementation pointers, I'd appreciate it.

The most difficult part seems to be adding a test case that will reliably pass whatever the local time the test is running under is.

Off the top of my head, my only idea is to pick time zones on either side of the international date line and assert that "today" in each of them differs by 1. I'm open to other suggestions for test cases.

[EltonCN]

This issue is still open? I would like to solve it.

[lucaswiman]

@EltonCN As far as I know it's still open. I didn't start on an implementation yet, so have at it!

[pganssle]

I am not a huge fan of datetime.date.today() in the first place, and I think it would be somewhat confusing if datetime.date accepted a tzinfo, then returned a naïve date (though date itself doesn't have a tzinfo parameter, so it doesn't make sense for it to be aware anyway).

I also find it a tiny bit icky that datetime.date needs to know about datetime.datetime for this to work, since tzinfo only works with datetime objects, but I guess there isn't an actual problem with that, per se.

I'm maybe +0 on this idea. @abalkin Any thoughts?

[StanFromIreland]

This could be done after existing issues are sorted out... #88473

[StanFromIreland]

I was looking into this today and I don't think that date should have tzinfo. If you want a tz aware date datetime already offers that.

I vote to keep date simple.

Paul, do you want to close this? There has not been much support for it, we can always come back to it in the future.

[pganssle]

Yes let's close this.