This basically exists, and it's called ISO 8601. But the scope of ISO 8601 isn't programming languages and APIs, but data models and their representations. A su

This basically exists, and it's called ISO 8601. But the scope of ISO 8601 isn't programming languages and APIs, but data models and their representations. A subset of ISO 8601 forms the basis of RFC 3339. Official copies of ISO 8601 are available for a fee from ISO. For the purposes of this discussion thread, consult this file hosted by the US Library of Congress for reference [1]. ISO 8601 defines a number of terms of art to represent a thorough mental model of the problem space, and then goes on to define string representations on how to express them. But it's paywalled, so people reach for RFC 3339 and the Wikipedia article instead. These focus on representations, and the definition of the concepts isn't captured clearly, so sometimes they're rediscovered independently. Other times, they're not. Serious attempts to figure this out usually coalesce to something that looks and behaves like Java 8 time. Java 8 time may be verbose, but its concepts are clearly mapped out, and the API bears some marks of a misuse-resistant design. Compared to that, there's efforts like the standard libs for Python, Ruby, Go, or most third-party libs for JS, Rust, that don't bring clarity to the table, and don't present any solution for dealing with calendrical or clock-face objects, and do little to discourage misuse of their point-in-time objects in abstract contexts. This proposal falls much, much closer to the Java 8 way than to the "everything is an instant, go make your own classes" way. One shortcoming of ISO 8601 is that it has no provisions for abstract timezones. Instead, people go outside of the standard to represent ISO datetimes alongside IANA timezones. But the most glaring problem with ISO 8601 is that it doesn't define partials where a more-significant term is unknown or missing: there's no valid, unambiguous way to refer to the 15th day of March, while leaving the year deliberately unspecified. This means that anniversary dates (e.g birthdays, holidays) aren't possible to represent in the abstract. Likewise, there's no valid, unambiguous way to refer to the 29th second of the fourth minute of every hour. This is much less important than the birthday shortcoming. The Library of Congress has a standard which extends ISO 8601 with a number of useful constructs for their purposes [2], like uncertainty qualifiers, but even that standard has no mechanism to represent a month+day partial in the abstract. [1] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... [2] https://www.loc.gov/standards/datetime/ https://www.loc.gov/standards/datetime/