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-le...@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/OJI3GBPNNGVZL22EAD723TYIFNF6OWAH/
Code of Conduct: http://python.org/psf/codeofconduct/
