David Morley <mor...@ai.sri.com> added the comment: > 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. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4775> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
