Brittle test

The test `test_expires_valid_str` fails on my OS X box, in Python 2.7:

``` python
============================= test session starts ==============================
platform darwin -- Python 2.7.5 -- pytest-2.3.4
plugins: cov
collected 116 items 

test_requests.py .................................................................................................................F..

=================================== FAILURES ===================================
_______________ TestMorselToCookieExpires.test_expires_valid_str _______________

self = <test_requests.TestMorselToCookieExpires testMethod=test_expires_valid_str>

    def test_expires_valid_str(self):
        """Test case where we convert expires from string time."""

        morsel = Morsel()
        morsel['expires'] = 'Thu, 01-Jan-1970 00:00:01 GMT'
        cookie = morsel_to_cookie(morsel)
>       assert cookie.expires == 1
E       AssertionError: assert -3599 == 1
E        +  where -3599 = Cookie(version=0, name=None, value=None, port=None, port_specified=False, domain='', domain_specified=False, domain_in...False, secure=False, expires=-3599, discard=False, comment='', comment_url=False, rest={'HttpOnly': ''}, rfc2109=False).expires

test_requests.py:1111: AssertionError
==================== 1 failed, 115 passed in 23.32 seconds =====================
```

I've not yet got a good theory for this, though I think it's telling that the error is one hour. I don't know _what_ it's telling though, because time is complicated.

Anyway, this test needs to be rewritten to be more accepting of breakage. It's also possible that the intermittent failure of this test represents a problem with the `morsel_to_cookie` function itself, in which case that needs rewriting.


Is that test case fails anytime in your OS X box?


Currently it fails consistently on my OS X box. I'll try my other systems as well to see if it's OS X-specific or something more general.


It passes for me on OSX right now, and I'll try my Linux box later. I expect it passes on Jenkins since we've had several successful PR builds.


Passes for me on my Windows box. Hmmmmmm.


Passes for me in OS X, Linux, Windows box. It may not OS dependent problem.


Weeeeeird. Weird. I'll rebuild my virtualenv and try again.


Nope, still failing with a new virtualenv.


I wonder if this is related to the `locale` variables:

```
LANG="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_CTYPE="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_ALL=
```


Probably not, `time.localtime()` is the same on my OS X box (that exhibits the problem) and on my Windows box, that does not.


What the fuck OS X?

``` python
>>> time.mktime((1970, 1, 1, 0, 0, 1, 3, 1, 0))
-3599.0
>>> time.gmtime(1)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=1, tm_wday=3, tm_yday=1, tm_isdst=0)
```

It doesn't roundtrip!

``` python
>>> time.gmtime(time.mktime((1970, 1, 1, 0, 0, 1, 3, 1, 0)))
time.struct_time(tm_year=1969, tm_mon=12, tm_mday=31, tm_hour=23, tm_min=0, tm_sec=1, tm_wday=2, tm_yday=365, tm_isdst=0)
```


``` pycon
Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.mktime((1970, 1, 1, 0, 0, 1, 3, 1, 0))
21601.0
>>> time.gmtime(1)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=1, tm_wday=3, tm_yday=1, tm_isdst=0)
>>> time.gmtime(21601.0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=6, tm_min=0, tm_sec=1, tm_wday=3, tm_yday=1, tm_isdst=0)
>>> time.mktime((1970, 1, 1, 0, 0, 1, 3, 1, 0))
21601.0
>>> time.gmtime(time.mktime((1970, 1, 1, 0, 0, 1, 3, 1, 0)))
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=6, tm_min=0, tm_sec=1, tm_wday=3, tm_yday=1, tm_isdst=0)
```


Yeah, that's what I thought, there's some horrible timezone related stuff here. This makes me very sad. =(


When i set timezone of my OS X machine to `Europe/London`, my test fails eventually
it exactly is timezone related problem :(


So while the test doesn't use `'maxage'` I wonder if [this line](https://github.com/kennethreitz/requests/ac4e05874a1a983ca126185a0e4d4e74915f792e/master/requests/cookies.py#L393) should account for `time.timezone`. If it should not, then why does [the line related to the test](https://github.com/kennethreitz/requests/blob/ac4e05874a1a983ca126185a0e4d4e74915f792e/requests/cookies.py#L397) accounting for timezones?

I'm very skeptical that our morsel handling here is correct.

FWIW not handling timezones seems like the right thing in the second link I posted:

``` pycon
Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time()
1389554633.231499
>>> time.time() - time.timezone
1389533037.127436
>>> time.strptime('Thu, 01-Jan-1970 00:00:01 GMT', '%a, %d-%b-%Y %H:%M:%S GMT')
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=1, tm_wday=3, tm_yday=1, tm_isdst=-1)
>>> time.gmtime(1)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=1, tm_wday=3, tm_yday=1, tm_isdst=0)
```

The only difference I see between `time.strptime` and `time.gmtime` is that the former has a different value for `tm_isdst`.


FWIW, the change I'm referencing was introduced around [this discussion](https://github.com/kennethreitz/requests/pull/1772#issuecomment-29958406)


Should we get someone in here who knows something about how the stdlib handles time? I just don't know anything like enough about what the correct behaviour is here.

BTW, `time.timezone` on my system is currently `0`, as it should be.


Can you post the result of the `time.mktime(time.strptime(...))` call from morsel_to_cookie?


Nevermind you just answered me in IRC, it's `-3599.0`.


Based on reading the `stdlib`, it looks like we're overcomplicating this. `time.mktime()` "expresses the time in _local_ time, not UTC", from which we subtract the timezone. Why not just use `time.gmtime()` and remove the timezone subtraction?


Ah, because they aren't the same, that's why. =P


This seems relevant:

``` python
>>> time.gmtime(0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
>>> time.localtime(0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
```


Why the hell is the relevant function [here](http://docs.python.org/2/library/calendar.html#calendar.timegm)?

``` python
>>> import calendar
>>> import time
>>> calendar.timegm(time.strptime('Thu, 01-Jan-1970 00:00:01 GMT', '%a, %d-%b-%Y %H:%M:%S GMT'))
1
```

@sigmavirus24 Can you confirm that works OK for you too?


Confirmation successful. All lights green wildcard


Should we close this to centralize discussion on #1860 ?


Yes. =)