limited time.gmtime() on 32-bit platforms.

Why is this actually an issue? No revisions in the wild should have been created before 2004 and nothing should currently exist beyond 2017; it will take another 22 years (when these Windows versions are long deprecated) before revisions with those timestamps will be created.

Jelmer it's an issue because you can set the date you want, and it will works on some systems and fail on windows and 32-bit ones.

Anything before 1900 gives an error on 64-bit as well, even with your fixes. Practically speaking, why do you need to set timestamps after 2039 ? Can't we just error when timestamps after 2039 are specified?

These changes introduce extra complexity that isn't necessary. I'd much rather just rely on the standard Python functionality.

Jelmer you are clearly blocking on this clean and simple fix for no reason.

It's a real problem for Breezy, because with this type of contibutions management, you don't risk to have other new contributors anymore... See "Hard to land patches"
https://www.jelmer.uk/pages/bzr-a-retrospective.html

The error before 1900 can be fixed, and yes it would be great, but step by step, this first fix is needed before.

Practically speaking it seems that you have a programmer only vision of the VCS use cases. This is the text of my Mercurial fix:
https://www.mercurial-scm.org/repo/hg//rev/87c6ad2251d8
"DVCS are very useful to store various texts (as legislation) written before Unix epoch."
The modifications of the laws and the applicable versions of the laws can also be planned in the (far) future.

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?

Do you plan to support Python 2.7 ? There will be not fix in Python 2.7

On Sun, Dec 03, 2017 at 11:54:01PM -0000, Florent Gallaire wrote:
> Do you plan to support Python 2.7 ? There will be not fix in Python 2.7
Yes, we're planning to support Python 2.7.

--
Jelmer Vernooij <email address hidden>
PGP Key: https://www.jelmer.uk/D729A457.asc

> Yes, we're planning to support Python 2.7.

So you need my patch...

That's still not clear to me.

Can we please clarify first what the problem is that we're trying to solve? That makes it a lot easier to determine if this is the correct approach. Is that problem solved by supporting pre-1970 dates but not pre-1900 dates?

I agree it's a problem that we print a traceback if the user passes a time string that Breezy doesn't support; at the very least we should be printing a proper error message in that case.

I'm unsure why it's necessary to increase the range of supported dates to pre-1970 but not pre-1900.

Martin mentions offline that another option to supporting wider time ranges times is to switch to using datetime internally, which would avoid the need to duplicate time.*.