Parsing dates with no times, without assuming default times

Is it possible to optionally get a datetime.date object out of a parser, instead of a datetime.datetime?

Essentially I'd like to differentiate between, say, "tomorrow" and "tomorrow 4pm", where the former would just give me date(2021, 6, 23), and the latter datetime(2021, 6, 23, 16, 0). I'm not sure if this exists as a feature already -- searching the docs and issues for the likes of "date without time" is tricky in a date-parsing library!

The current behaviour is for "tomorrow" to give me datetime(2021, 6, 23, 13, 0), i.e. the current time one day away, which for my use case (semi-free text calendar entry creation) isn't very intuitive. The workaround I've got currently is a first pass scan of the input, extracting variants of "all day" and setting a flag to strip the time components later, which also isn't ideal.

As a feature request

I believe we should still always return a datetime by default, so as not to break any existing compatibility. This could be put behind a new setting, such that parsing a string would result in one of:

• always a datetime (the default, and current behaviour)
• always a date, ignore times
• prefer a datetime, unless "all day" text is detected (in which case ignore any times)
• prefer date, unless time text detected (in which case ignore any "all day"s)

The third case could alternatively just be done without a setting, by checking for the presence of "all day" or variants, though callers would need to be aware that they might not get a datetime back.

The issue does not name specific files, tests, or entry points. Start by locating the parser behavior that supplies default times and reviewing how parser settings are defined. Done means introducing a compatible way to distinguish date-only input from explicit times while preserving the current datetime default.