Tests don't work on leapdays

Bug #1551189 reported by Sean Dague
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Matthew Edmonds

Bug Description

2016-02-29 08:57:08.024 | Captured traceback:
2016-02-29 08:57:08.025 | ~~~~~~~~~~~~~~~~~~~
2016-02-29 08:57:08.025 | Traceback (most recent call last):
2016-02-29 08:57:08.042 | File "keystone/tests/unit/test_backend.py", line 5555, in test_list_trust_by_trustor
2016-02-29 08:57:08.042 | self.create_sample_trust(uuid.uuid4().hex)
2016-02-29 08:57:08.042 | File "keystone/tests/unit/test_backend.py", line 5475, in create_sample_trust
2016-02-29 08:57:08.042 | expires_at = datetime.datetime.utcnow().replace(year=2031)
2016-02-29 08:57:08.042 | ValueError: day is out of range for month

The keystone test code assume all months have the same length in all years. That is not the case.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/285987

Changed in keystone:
assignee: nobody → Sean Dague (sdague)
status: New → In Progress
Sean Dague (sdague)
Changed in keystone:
status: In Progress → Confirmed
importance: Undecided → High
Changed in keystone:
assignee: Sean Dague (sdague) → Matthew Edmonds (edmondsw)
status: Confirmed → In Progress
Changed in keystone:
milestone: none → mitaka-3
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/285987
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7c6556ce18eb170fd8102168b33a50272b22ec5a
Submitter: Jenkins
Branch: master

commit 7c6556ce18eb170fd8102168b33a50272b22ec5a
Author: Sean Dague <email address hidden>
Date: Mon Feb 29 06:31:40 2016 -0500

    Make keystone tests work on leap years

    A bunch of tests have to do with fast forwarding time to figure out
    what happens with expirations. That is done with a naive .replace on
    year. Which is fine, except on Feb 29th, because the python code does
    care if something is a valid datetime. Previously 2030 and 2031 were
    used as magic years. Neither is a leap year. Fast forwarding to that
    year on Feb 29th is a fatal python error.

    Narrowly fix this by using 2028 and 2032 instead. A better solution
    should probably be implemented long-term, but until this is landed
    keystone is blocked.

    Change-Id: If13e53bd5d4ace2a53a245d74166e4f3b1c34d4a
    Closes-Bug: #1551189

Changed in keystone:
status: In Progress → Fix Released
Revision history for this message
Thierry Carrez (ttx) wrote : Fix included in openstack/keystone

This issue was fixed in the openstack/keystone development milestone.

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

Other bug subscribers