> I propose to add this sentence to the explanation of the epoch:
>
> "It is platform-dependent whether or not 'seconds since the epoch'
> includes leap seconds. Most systems likely implement `Unix time`_"

That solution is fine.

Anyone sufficiently concerned about the implications can then work out 
the consequences for themselves once alerted.

> Please, one issue at a time. I believe that this doesn't crop up,
> or if it does, it's a different issue. If you want to pursue this,
> please create a separate report, and preferably include a proposed
> wording.

This was in response to your request for "specific other usage of UTC". 
The datetime module uses the term UTC very frequently but assumes a 
fixed 86400 second day (which is incompatible with UTC but compatible 
with the other Universal Times). I see this as the same issue, that is, when leap-seconds are not used it seems odd to use the more specific 
term "UTC" rather than the less specific "GMT" or "UT" - "UTC" is a more 
precise but in this case less accurate term.

...but I am happy to drop this if you don't consider it a problem.

> Why do you think UT1 plays any role here?

To me, but maybe not to anyone else :-), property (1a) eliminates the 
usefulness of the numerical representation of time for interpretation 
(1) of the time routines.

Of the non-UTC versions of Universal Time why did I assume UT1 
specifically? UT1 is the main Universal Time - the one that UTC attempts 
to approximate.

> Computers *have* to use
> SI seconds, since they are not physically equipped to measure
> anything else (unless you want to get even more nit-picking and point
> out that the quartz in the computer is not capable of measuring
> SI seconds exactly).

Well, the different Universal Times *are* nit-picking over defining 
seconds :-) Without the nit-picking, we would have GMT.