I would say that the natural output of mktime is indeed an integer, but I can't say off the top of my head what "compatibility" refers to here, so per the principle of Chesterton's fence, without more research or historical context I'd say the default should be *not* to make this change.

At the moment, I'm -0 on this, because "we should have designed the API this way in the first place" doesn't seem like a good enough reason to change the return type. I doubt it would be *terribly* onerous to the users to change this, so if there's some compelling reason for making it an integer I'm willing to be persuaded, but as it stands I don't think this is causing a huge amount of confusion or problems.

One other possible reason to mildly prefer no change is that if we were to change `struct_time` to accept a float for `tm_sec` (which I imagine might have more widespread consequences, admittedly), it wouldn't require a change to `mktime` to support sub-second offsets. Again, a compelling use case for an `int` return value could pretty easily overwhelm this objection.

> mktime() will not start losing precision before year 285,422,891 (which is quite far in the future ;-)).

I think we're witnessing the birth of the Y285M422K891 bug! winking face emoji