[Python-Dev] bpo-36558: Change time.mktime() return type from float to int? (original) (raw)

Paul Ganssle paul at ganssle.io
Tue Apr 16 10:41:05 EDT 2019

I already chimed in on the issue, but for the list, I'll boil my comments down to two questions:

  1. For anyone who knows: when the documentation refers to "compatibility with .time", is that just saying it was designed that way because .time returns a float (i.e. for /consistency/ with .time()), or is there some practical reason that you would want .time() and .mktime() to return the same type?

  2. Mainly for Victor, but anyone can answer: I agree that the natural output of mktime() would be int if I were designing it today, but would there be any /practical/ benefits for making this change? Are there problems cropping up because it's returning a float? Is it faster to return an integer?

Best,

Paul

On 4/16/19 10:24 AM, Victor Stinner wrote:

Hi,

time.mktime() looks "inconsistent" to me and I would like to change it, but I'm not sure how it impacts backward compatibility. https://bugs.python.org/issue36558 time.mktime() returns a floating point number:

type(time.mktime(time.localtime())) <class 'float'> The documentation says: "It returns a floating point number, for compatibility with :func:.time." time.time() returns a float because it has sub-second resolution, but the C function mktime() returns an integer number of seconds. Would it make sense to change mktime() return type from float to int? I would like to change mktime() return type to make the function more consistent: all inputs are integers, it sounds wrong to me to return float. The result should be integer as well. How much code would it break? I guess that the main impact are unit tests relying on repr(time.mktime(t)) exact value. But it's easy to fix the tests: use int(time.mktime(t)) or "%.0f" % time.mktime(t) to never get ".0", or use float(time.mktime(t))) to explicitly cast for a float (that which be a bad but quick fix). Note: I wrote and implemented the PEP 564 to avoid any precision loss. mktime() will not start loosing precision before year 285,422,891 (which is quite far in the future ;-)). Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20190416/1a2f7454/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://mail.python.org/pipermail/python-dev/attachments/20190416/1a2f7454/attachment-0001.sig>

More information about the Python-Dev mailing list