+1. I would suggest `fromtimestamp` also accept an optional timezone argument. On Sun, 2022-06-19 at 11:47 -0700, Lucas Wiman wrote:

Since "today" depends on the time zone, it should be an optional argument to date.today(). The interface should be the same as datetime.now(tz=None), with date.today() returning the date in the system time zone.

Rationale: It is common for processes to run in different timezones than the relevant end user. The most common case is probably a server running in UTC, which needs to do date calculations in timezones elsewhere. As a contrived example, you might do something like:

    tomorrow =date.today() + timedelta(days=1)     return render_template(..., ship_by_date=tomorrow)

But then if fulfillment is operating e.g. in US/Pacific time, the ship by date suddenly shows two days hence after 5 or 6pm when UTC midnight happens.

In my particular use case, we get some collection of business rules about when a particular record is considered "stale" or prioritized, and naively using date.today() can lead to off-by-one errors.

The way to "fix" the code above is to reference "now":

    tomorrow =datetime.now(tz=...).date() + timedelta(days=1)     return render_template(..., ship_by_date=tomorrow)

While this is not terrible, it seems like the API between now() and today() should be consistent: in reality, they need the same set of inputs. Calling date.today(...) is more explicit and specific than calling datetime.now(...).date().

Best wishes, Lucas

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OJI3GB... Code of Conduct: http://python.org/psf/codeofconduct/