I don’t think the issue is a lack of adherence to international standards. The Dates module does aim to adhere to an international standard, however, it’s one for representing, communicating, and doing simple calendar arithmetic on Gregorian calendar dates and 24-hour time of day (ISO 8601), not one for precision timekeeping (these are really quite unrelated concerns). It can be useful for things like timestamps in database records, but probably not for astronomy and GNSS, and this is arguably the correct tradeoff for a standard library.
Specifically, the documentation states that Dates assumes Universal Time - Wikipedia, which is basically solar time, meaning that the lengths of days and seconds are nonuniform due to variations in the earth’s rotation. This is convenient because it means each day has exactly 86400 seconds and you don’t have to fuss with leap seconds in DateTime arithmetic, but it also means that even millisecond precision is a bit nonsensical, and locating events with nanosecond precision on a timeline that’s uniform across centuries is way beyond the scope of the module.
The mystery here is really why the module supports sub-millisecond intervals at all, given the other design decisions. Perhaps the solution is to deprecate Microsecond and Nanosecond and point users to appropriate packages?