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

Bug #1670243 reported by Florent Gallaire on 2017-03-06
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Florent Gallaire
Breezy
Undecided
Unassigned

Bug Description

time.gmtime() can't handle date before 1901 and after 2038 on 32-bits platforms.

[flext@web99 tb]$ python2.7 ../BZRR/bzr/bzr commit --commit-time "1900-01-01 00:00:00 +0000"
bzr: ERROR: exceptions.ValueError: timestamp out of range for platform time_t
[...]
  File "/home/flext/BZRR/bzr/bzrlib/osutils.py", line 928, in compact_date
    return time.strftime('%Y%m%d%H%M%S', time.gmtime(when))
ValueError: timestamp out of range for platform time_t

bzr 2.8.0dev1 on python 2.7.12 (Linux-2.6.18-416.el5PAE-i686-with-
    redhat-5.11-Final)

[flext@web99 tb]$ python2.7 ../BZRR/bzr/bzr commit --commit-time "2039-01-01 00:00:00 +0000"
bzr: ERROR: exceptions.ValueError: timestamp out of range for platform time_t
[...]
  File "/home/flext/BZRR/bzr/bzrlib/osutils.py", line 928, in compact_date
    return time.strftime('%Y%m%d%H%M%S', time.gmtime(when))
ValueError: timestamp out of range for platform time_t

bzr 2.8.0dev1 on python 2.7.12 (Linux-2.6.18-416.el5PAE-i686-with-
    redhat-5.11-Final)

Related branches

summary: - limited time.gmtime() on 32-bits platforms.
+ limited time.gmtime() on 32-bit platforms.
Vincent Ladeuil (vila) on 2017-03-15
Changed in bzr:
assignee: nobody → Florent Gallaire (fgallaire)
importance: Undecided → Medium
milestone: none → 2.8b1
status: New → In Progress
Jelmer Vernooij (jelmer) wrote :

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.

Florent Gallaire (fgallaire) wrote :

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.

Jelmer Vernooij (jelmer) wrote :

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.

Florent Gallaire (fgallaire) wrote :

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.

Jelmer Vernooij (jelmer) wrote :

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?

Florent Gallaire (fgallaire) wrote :

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

Florent Gallaire (fgallaire) wrote :

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

So you need my patch...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers