UTC itself does not ignore leap seconds, 2016-12-31T23:59:59.314Z is a valid UTC time according to ISO 8601. Almost all software systems (databases, etc.) cannot handle the leap seconds and assume that each day has 86400 s. Julia is not worse in this respect, but I have ideas how to make it better without throwing the existing DateTime completely over board:
Internally times inside leap seconds should be representable, in order to be able to time stamp real events. This is difficult, if you count the nr of seconds (or milliseconds…) from a certain epoch, like the POSIX time in seconds from 1970-01-01. Then the leap seconds collide with the assumption that every day has 86400. If the internal representation is day segmented (my previous post), no problem to represent timestamps inside leap seconds. Conversion back to date/time strings is not more complicated than with single counters, rather easier. Performance hit and additional memory is probably negligible.
Conversion to TAI, GPS can be handled in a packages, probably not so many users need it.
UT1 has a definition connected to the Earth rotation, and it is measured and changes all the time relative to UTC. Whenever the difference exceeds about 1.5 s, a leap second is inserted into UTC, to bring the difference down again. So yes, UT1 doesn’t have leap seconds, but it also really doesn’t have years, months, days. From an IT viewpoint it is just a table of differences to UTC.
Ok, I see now that I should send this Julep, …