Aren’t all of those example problems solved with a versioned database of timezones and calendar algorithms? Any past “universal” date can be converted to a fully defined local, contextual time based on such a resource. But, it doesn’t exist.
In theory it's a solvable problem. In practice most libraries handling date and time aren't living up to that expectation, in particular and core system libraries, because it's just hard and tradeoffs are made.
Such databases do exist, and they're how more heavyweight libraries solve the problem. But there has to be code that applies the algorithms; there has to be a reasonable guarantee that the code will actually be used in the appropriate situations; and dates need to encode the information about which database version to use (otherwise you will run into problems e.g. if you're trying to plan around future dates; "render the date according to the current rules for the current locale" isn't always correct, and "render the date according to the rules for the place and time when and where the object was created / data was stored" isn't either, and "render the date according to the rules for the place and time that it represents" isn't either).
tl;dr: dates are hard because they represent an intersection between adjusting a model to meet physical reality, with l10n/i18n concerns (even if you don't care about language translation). Both of those are hard enough individually already.
