Comment 5 for bug 1670243

I'm pushing back because I'm not convinced this is solving an actual problem, and it's not a trivial change. Do you actually have digitized documents from before 1901 that you want to import into Bazaar/Breezy.

On the other hand, this is adding complexity to Breezy. Not just in the sense that it's more code but also:

 * We will no longer get bug fixes that happen in upstream Python time functions
 * Future patches will need to remember to use osutils.* rather than time.*
 * We might introduce crashes in codepaths that don't deal well with non-time_t time values; but we're unlikely to notice as we're on 64-bit

The Mercurial change that you link to is isolated to a single Python function that deals with time; that's a much more reasonable change IMHO.

This leads us down a path where we have a 64-bit reimplementation of the Python time module functions in osutils (at least gmtime, localtime, strftime and strptime). Can't we fix this in upstream Python? Or if we really must, can you publish a "time64" Python module that mimicks the Python time module that we can import these functions from instead?