[atsmyles]

No/No/No definitively. Dates without times are ranges. If one person is born on 2022-06-01 12:00:00 and another person was born on 2022-06-01 13:00:00 then they have the same birthday 2022-06-01. It follows, that if you know that 2 people are born on the same day such as 2022-06-01, then it is unknown if they were born on the same time. So adding a default time to a day (such as 00:00:00) is nonsensical.

[noitpmeder]

Dates without times are... Dates? Aren't we talking about two distinct types here?

Drawing examples from pythons stdlib there are (roughly) three types: dates, datetimes (tz naive), and datetimes (tz aware)

[Izkata]

> Dates without times are... Dates? Aren't we talking about two distinct types here?

I assume this is a response to specifically this part:

> Dates without times are ranges.

If we're talking conceptually about general date/time/datetime comparisons, not pegged to a specific programming language or type system, I agree with it: Dates are a 24-hour range.

[masklinn]

> Dates are a 24-hour range.

If you consider that dates are ranges, they’re not 24h but 50 (currently, can change) since a dare has no zoning information: a given date starts at 00:00 on Kiribati (UTC+14:00) and ends the same on Baker (UTC-12:00).

[NateEag]

Caveat:

The date's range isn't always 24 hours exactly.

Leap seconds can make it slightly longer.

A daylight savings change makes the date's range 23 or 25 hours, depending on the direction.

I would not be surprised if someone popped up with more edge cases I haven't thought of.

Dates and times are crazy.

[PeterisP]

If you're treating dates as ranges, then even ignoring the timezones and daylight savings it still doesn't mean that a date implies a range from 00:00 to 24:00 - the mapping is inherently domain-specific and thus depends on the particular interpretation of that date field (thus it's nonsensical to expect a generic answer/comparison rule for "dates" i.e. all dates).

For example, in the domain of financial settlement, a future date of 2022-03-03 would imply that the event must happen by the end of business day of 2022-03-03 (and thus an event at 23:00 of 2022-03-03 would be too late and would map to 2022-03-04 instead); and in a similar manner, the appropriate date for any events happening in the middle of a sunday would be either monday or friday depending on what your rules are, as the effective date which you would be using to calculate the number of days between two events (for e.g. interest) in may jurisdictions has to be a business day; so two events timpestamped five minutes apart might need to be treated as if they are on the same day, different days, or in some cases many days apart (e.g. with a combination of Christmas + weekend).

Different domains will have different rules; the generic concept of "date" is too vague to define an universal comparison operator and you have to look at the meaning of each specific date field/variable and expect different date fields/variables to need different semantics.

[NateEag]

This is an excellent point. Thank you for sharing it!

[anonymoushn]

Dates last about 48 hours!

[jimmar]

Wouldn't dates with times also be ranges? The ranges are just tighter. If something happened at 11:02AM, did it really happen at 11:02AM? Or did it really happen somewhere between 11:02.0AM and 11:02.99999AM?

[NateEag]

Yes.

You can frame this from either the perspective of ranges or the perspective of degrees of precision.

I think both are valid, useful conceptions. You could argue they're semantically identical, I think?