Is Date ISO-8601?

[Seelengrab]

This came up in discussion on #49700.

The general thinking/issue is that Date doesn't (and can't) have time associated with it, yet conversion to DateTime arbitrarily picks 00:00 as a default:

julia> using Dates

julia> convert(DateTime, today())
2023-05-15T00:00:00

This is a potential (undocumented) footgun. While Base does not care for timezones (reasonably so), I'd argue that this is a correctness bug waiting to happen - a Date does not have a time associated with it after all, and as such this should error & a default be provided by the user.

The reasoning for this is simple - in some timezones (even though Base is oblivious to those), there are dates where there is no 00:00, not even in local time. A default that is sometimes not even incorrect is just a plain bad default, and IMO, should be changed.

Further, since ISO-8601actually defines two midnights, the question is whether DateTime is even ISO-8601 compliant (or whether we want it to be/keep it compliant with newer versions..).

As of ISO 8601-1:2019/Amd 1:2022, midnight may be referred to as "00:00:00", corresponding to the instant at the beginning of a calendar day; or "24:00:00", corresponding to the instant at the end of a calendar day.[1] ISO 8601-1:2019 as originally published removed "24:00" as a representation for the end of day although it was permitted in earlier versions of the standard.

We silently convert the latter to the former of the next day on construction, which I believe is incorrect:

julia> DateTime(2023, 5, 13, 24, 0, 0)
2023-05-14T00:00:00

I guess the larger question around this is whether Dates should be an stdlib at all, since the field is changing all the time and keeping Dates "fixed in time" (no pun intended) seems like it would just end up accumulating inconsistencies and bugs, through no fault of its own. Maybe it's a good candidate for future excision?