> As it is now, I can find all events based just on EventDate without a worry about the timestamp:As it is now, I can find all events based just on EventDate without a worry about the timestamp: > ... > If they're combined, the same query is useless: > ... Certainly, if you care only to resolve dates, and times are an entirely separate concern, that separation is not causing too much trouble. But when your events have a duration, perhaps represented with an event_begin and event_end datetime, the ISO 8601 representation's merit will become more apparent. Programmers like it because its lexical ordering and its time ordering are the same. Suppose that your EventDate becomes EventDateTime, using ISO 8601:<code> ┌──────────────────┐ │ EventDateTime │ ├──────────────────┤ │ 2021-04-10T13:30 │ │ 2021-04-11T04:15 │ │ 2021-04-11T05:45 │ │ ... │ └──────────────────┘ </code>. Now you want a query which counts events by day, dropping the time (ignoring the ambiguity of "day" going around the world.) A <code> GROUP BY substring(EventDateDtime, 1, 10) </code>clause gets that. Seems like extra trouble for just that usage. Suppose you want events falling within a date range. A <code> WHERE EventDateDtime BETWEEN 2021-04-10T00:00 AND 2021-04-11T23:59 </code>clause would capture the above 3 datetimes. This is very little extra trouble. Now imagine you are writing a query to look for scheduled timeslot gaps in an event location which is open through midnight. Then, you will find that having a simply ordered time representation pays off. There is a reason that ISO 8601 has become beloved by programmers. Among the textual time representations, it has no peer.