cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead.Example from the docs [2] is seven hours off (it shows utc offset of the local timezone of the person who created it):    >>> import ssl    >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")1178694000.0It should be `1178668800`:    >>> from datetime import datetime    >>> datetime.utcfromtimestamp(1178668800)    datetime.datetime(2007, 5, 9, 0, 0)    >>> import time    >>> time.gmtime(1178668800)    time.struct_time(tm_year=2007, tm_mon=5, tm_mday=9, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=129, tm_isdst=0)And `calendar.timegm` returns correct result:    >>> calendar.timegm(time.strptime("May 9 00:00:00 2007 GMT", "%b %d %H:%M:%S %Y GMT"))1178668800[1]:http://hg.python.org/cpython/file/96a68e369d13/Lib/ssl.py#l849[2]:http://hg.python.org/cpython/file/96a68e369d13/Doc/library/ssl.rst#l359

Will work on this.Please assign the issue to me.Instructions before proceeding by Tim Golden(python mailing list):Having just glanced at that issue, I would point out that there's been alot of development around the ssl module for the 3.4 release, so youdefinitely want to confirm the issue against the hg tip to ensure itstill applies.

Indeed the example in the docs is wrong, and so is the current behaviour.The example shows "round-tripping" using ssl.cert_time_to_seconds() and then time.ctime(), except that it is bogus as it takes a GMT time and ctime() returns a local time ("""Convert a time expressed in seconds since the epoch to a string representing local time""").Still, we should only fix it in 3.4, as code written for prior versions may rely on the current (bogus) behaviour.

gudge, your contribution is welcome! If you need guidance about how to write a patch, you can read the developer's guide:http://docs.python.org/devguide/Also you will have to sign a contributor's agreement:http://www.python.org/psf/contrib/

gudge,There is also an issue with the current strptime format [1] (`"%b %d %H:%M:%S %Y GMT"`). It is locale-dependent and it may fail if a non-English locale is in effect. I don't know whether I should open a new issue on this or are you going to fix it too.`cert_time_to_seconds()` is documented [2] to parse notBefore, notAfter fields from a certificate. As far as I can tell they do not depend on current locale. Thus the following code should not fail:    >>> timestr = "May  9 00:00:00 2007 GMT"    >>> import ssl    >>> ssl.cert_time_to_seconds(timestr)1178661600.0    >>> import locale    >>> locale.setlocale(locale.LC_TIME, 'pl_PL.utf8')    'pl_PL.utf8'    >>> ssl.cert_time_to_seconds(timestr)    Traceback (most recent call last):    ...[snip]...    ValueError: time data 'May  9 00:00:00 2007 GMT' does not match format '%b %d %H:%M:%S %Y GMT'[1]:http://hg.python.org/cpython/file/96a68e369d13/Lib/ssl.py#l849[2]:http://hg.python.org/cpython/file/96a68e369d13/Doc/library/ssl.rst#l359

1) Can I get a list of failures. The summary of test results which I compare on my machine.2) ----------------------------------------------------------------------------------------------------->>> import ssl>>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")1178649000.0>>> from datetime import datetime>>> datetime.utcfromtimestamp(1178668800)datetime.datetime(2007, 5, 9, 0, 0)>>> import time>>> time.gmtime(1178668800)time.struct_time(tm_year=2007, tm_mon=5, tm_mday=9, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=129, tm_isdst=0)>>> import calenderTraceback (most recent call last):  File "<stdin>", line 1, in <module>ImportError: No module named 'calender'>>> import callendarTraceback (most recent call last):  File "<stdin>", line 1, in <module>ImportError: No module named 'callendar'>>> import calendar>>> calendar.timegm(time.strptime("May 9 00:00:00 2007 GMT", "%b %d %H:%M:%S %Y GMT"))1178668800----------------------------------------------------------------------------------------------------I am running a VM on windows host machine.In your comment ou have specified:>>> import ssl    >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")1178694000.0It should be `1178668800`:But I get also get the same answer with the Python build from latest sources?Therefore I do not get you?3)    3 tests omitted:        test___all__ test_site test_urllib2net    348 tests OK.    3 tests failed:        test_codecs test_distutils test_ioctl    2 tests altered the execution environment:        test___all__ test_site    33 tests skipped:        test_bz2 test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp        test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu        test_dbm_ndbm test_devpoll test_gzip test_idle test_kqueue        test_lzma test_msilib test_ossaudiodev test_readline test_smtpnet        test_socketserver test_sqlite test_ssl test_startfile test_tcl        test_timeout test_tk test_ttk_guionly test_ttk_textonly        test_urllibnet test_winreg test_winsound test_xmlrpc_net        test_zipfile64 test_zlibAre these results fine. These results are with no changes. How can I make all tests (skipped and omiited pass)What about the 3 tests which failed. Are these known failures?4)  Now say I have to pull time again to get the latest code. Does it helpto do a make. Or I will have o do configure again.5) I had posted a query on core-metorship? No answers? Not that I am entitled to.Thanks

Sorry I think I did not readmsg205774 (1st comment) correctly.It clearly says:"cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead."So the function cert_time_to_seconds() has to be fixed?Thanks

> So the function cert_time_to_seconds() has to be fixed?Yes!

Patch is uploaded.I will also copy paste it.I have created the patch with git. Let me know if it is okay with you. If it is unacceptable I will try and create one for mercuryPatch:------------------------------------------------------------------diff --combinedDoc/library/ssl.rstindex a6ce5d6,30cb732..0000000--- a/Doc/library/ssl.rst+++ b/Doc/library/ssl.rst@@@ -366,7 -366,7 +366,7 @@@ Certificate handlin         >>> import ssl       >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT") -1178694000.0 +1178668800        >>> import time       >>> time.ctime(ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT"))       'Wed May  9 00:00:00 2007'diff --combinedLib/ssl.pyindex f81ef91,052a118..0000000--- a/Lib/ssl.py+++ b/Lib/ssl.py@@@ -852,8 -852,7 +852,8 @@@ def cert_time_to_seconds(cert_time)      a Python time value in seconds past the epoch."""        import time -    return time.mktime(time.strptime(cert_time, "%b %d %H:%M:%S %Y GMT")) +    import calendar  +    return calendar.timegm(time.strptime(cert_time, "%b %d %H:%M:%S %Y GMT"))    PEM_HEADER = "-----BEGIN CERTIFICATE-----"  PEM_FOOTER = "-----END CERTIFICATE-----"-----------------------------------------------------------------Test Results:358 tests OK.1 test failed:    test_compileall1 test altered the execution environment:    test___all__28 tests skipped:    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu    test_dbm_ndbm test_devpoll test_idle test_kqueue test_lzma    test_msilib test_ossaudiodev test_smtpnet test_socketserver    test_sqlite test_startfile test_tcl test_timeout test_tk    test_ttk_guionly test_ttk_textonly test_urllibnet test_winreg    test_winsound test_xmlrpc_net test_zipfile64------------------------------------------------------------------------Doc changes won't effect the code. The tests would not fail. How would I check if the doc changes are coming up fine in the final version.>>> import ssl>>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")1178668800I do not have a printer curretly. I will sign the license agreement in a few days.

Answering to your questions:> I have created the patch with git. Let me know if it is okay with you.Yes, it's ok.Also, please don't copy / paste it. Uploading is enough.> Doc changes won't effect the code. The tests would not fail. > How would I check if the doc changes are coming up fine in the > final version.Thedevguide has detailed documentation about how to modify and buildthe documentation :)http://docs.python.org/devguide/documenting.html#building-the-documentationAs for the tests:1. for this issue you should probably concentrate on test_ssl: to run itin verbose mode, "./python -m test -v test_ssl"(please readhttp://docs.python.org/devguide/runtests.html)2. you will need to add a new test to test_ssl, to check that this bugis indeed fixed

gudge, have you seenhttp://bugs.python.org/msg205860 (the locale issue)?If you can't fix it; say so, I'll open another issue after this issue is fixed.

Akira, I will fix it. I will put in the patch in the same bug.

1) I understand I can run a whole test suite as./python -m test -v test_abcas mentioned inhttp://docs.python.org/devguide/runtests.htmlHow do I run a particluar test case, like the test I addedtest_cert_time_to_seconds2) I have a added a test case test_cert_time_to_seconds to test_ssl.py. 3) ./python -m test -v test_ssl   is all PASS.4) I will start my work onhttp://bugs.python.org/issue19940#msg205860.5) The patch is attached.

Can you please provide some hints on how to handlehttp://bugs.python.org/issue19940#msg205860.The value of format_regex1) Without locale set:re.compile('(?P<b>jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\\s+(?P<d>3[0-1]|[1-2]\\d|0[1-    9]|[1-9]| [1-9])\\s+(?P<H>2[0-3]|[0-1]\\d|\\d):(?P<M>[0-5]\\d|\\d):(?P<S>6[0-1]|[0-5]\\d|\\d)\\s    +(?P<Y>\\d\\d\\d\\d, re.IGNORECASE)2) With locale set:re.compile('(?P<b>sty|lut|mar|kwi|maj|cze|lip|sie|wrz|pa\\ź|lis|gru)\\s+(?P<d>3[0-1]|[1-2]\\d|0[    1-9]|[1-9]| [1-9])\\s+(?P<H>2[0-3]|[0-1]\\d|\\d):(?P<M>[0-5]\\d|\\d):(?P<S>6[0-1]|[0-5]\\d|\\d)\    \s+(?P<Y>\\d\\d\\d\, re.IGNORECASE)The value of months are different.Thanks

The point of the locale issue is that "notBefore", "notAfter" strings do not change if your locale changes. You don't need a new regex for each locale.I've attached ssl_cert_time_seconds.py file that contains example cert_time_to_seconds(cert_time) implementation that fixes both the timezone and the locale issues.

Akira, do you want to write a proper patch with tests? If you are interested, you can take a look athttp://docs.python.org/devguide/You'll also have to sign a contributor's agreement athttp://www.python.org/psf/contrib/contrib-form/

Antoine, I've signed the agreement. I've added ssl_cert_time_toseconds.patch with code, tests, and documention updates.

Akira, thanks. I have posted a review; if you haven't received the e-mail notification, you can still access it athttp://bugs.python.org/review/19940/#ps11142

Antoine,  I haven't received the e-mail notification.I've replied to the comments on Rietveld.Here's the updated patch with the corresponding changes.

Here's a new patch with a simplified ssl.cert_time_to_seconds()implementation that brings strptime() back.The behaviour is changed:- accept both %e and %d strftime formats for days as strptime-based implementation did before- return an integer instead of a float (input date has not fractions of a second)I've added more tests.Please, review.

Replace IndexError with ValueError in the patch because tuple.index raises ValueError.

I've updated the patch:- fixed the code example in the documentation to use int instead of  float result- removed assertion on the int returned type (float won't lose precision  for the practical dates but guaranteeing an integer would be nice)- reworded the scary comment- removed tests that test the testsReady for review.

Thanks for the updated patch, Akira! I'm gonna take a look right now.

New changeset7191c37238d5 by Antoine Pitrou in branch 'default':Issue#19940: ssl.cert_time_to_seconds() now interprets the given time string in the UTC timezone (as specified in RFC 5280), not the local timezone.http://hg.python.org/cpython/rev/7191c37238d5

I've committed the patch. Thank you very much for contributing!

Antoine, thank you for reviewing. I appreciate the patience.