Set owner to @floitschG.
Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

This would be useful, but so would the corresponding
  d1.time == d2.time
and it's an interesting question what those would return. A date with its other fields zeroed out would work for comparing the dat portion, but not for the time. You could possibly return something like the number of some unit since EPOCH, but that would likely be confusing for naive uses of aDate.time -> some very large integer. And that would break on Javascript.

This comment was originally written by thebinarysearcht...@gmail.com

Maybe avoid exposing properties and instead have methods that perform comparisons, such as d1.IsAtSameTimeOfDayAs(d2)

hah.

Removed the owner.

This issue originates from that fact that the modeling of date is incorrect under DateTime, which holds superfluous and wrong information about a date ( if it's only a date).

I would say having two additional types ( Date & Time ) would solve this issue. Both could be merged to form a DateTime if needed.

final time = Time.now();
final date = Date.today();
final dateTime = DateTime.fromParts(date, time);
final inTenSeconds = time.add(const Duration(seconds: 10));
final tomorrow = Date.tomorrow();
final nextDateTime = DateTime.fromParts(date, inTenSeconds)); // copy with time
final tomorrowDateTime = DateTime.fromParts(tomorrow, time)); // copy with date

Those are real world, everyday distinct values, that are in everyday conversations. As such I think those should be part of the sdk.

The main issue I have with DateTime representing a date is that it furnish an incorrect api, an user might call date.hour which is invalid.

The main issue I have with no Time type is that every library that needs it implements their own little class, so you end up mapping from your internal implementation, to flutter, to another impl.

Note: Ranges would also be nice. DateRange, TimeRange, DateTimeRange.

The recommended approach is to represent a plain dates ("calendar date") as a UTC DateTime with zero hours, minutes, seconds and microseconds.
A plain time ("clock time"), is probably best represented as a Duration.

You can still ask a UTC plain date about its hours (it'll be zero).

As long as you stay away from local-time DateTimes, you should avoid most of the pitfalls.

The "recommended" approach (and only remotely accurate approach that is using DateTime) still suffer from incorrect modeling and incorrect api surface. Ence my proposal of multiple types that more accurately represent reality. The fact that it also solves every issue cited here is also telling. Is there something you do not like about that proposal ? I know most languages I used do not make the distinction, that could be an hint that there is something bad about it. I was thinking maybe serialization but daysSinceEpoch would be as valid as millis, or maybe timezones would break that ?

No matter how documented it is, if it's not enforced by the compiler, someone will use the DateTime.hour to compare it to DateTime.now() and that will lead to an issue, which would have been easily avoidable if it was modeled correctly.

So I'm not a fan of the recommended approach, even if that's what I use.