<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I already chimed in on the issue, but for the list, I'll boil my
comments down to two questions:<br>
<br>
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 <i>consistency</i>
with `.time()`), or is there some practical reason that you would
want `.time()` and `.mktime()` to return the same type?<br>
<br>
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 <i>practical</i> benefits for
making this change? Are there problems cropping up because it's
returning a float? Is it faster to return an integer?<br>
<br>
Best,<br>
<br>
Paul<br>
</p>
<div class="moz-cite-prefix">On 4/16/19 10:24 AM, Victor Stinner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+3bQGFMC7JVY2sbr65iXG+6t_ZmF3S-3M530-o8cuyS6xqcLg@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi,
time.mktime() looks "inconsistent" to me and I would like to change
it, but I'm not sure how it impacts backward compatibility.
<a class="moz-txt-link-freetext" href="https://bugs.python.org/issue36558">https://bugs.python.org/issue36558</a>
time.mktime() returns a floating point number:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">type(time.mktime(time.localtime()))
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap=""><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
</pre>
</blockquote>
</body>
</html>