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.
Reviewed: https:/ /review. openstack. org/285987 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=7c6556ce18e b170fd8102168b3 3a50272b22ec5a
Committed: https:/
Submitter: Jenkins
Branch: master
commit 7c6556ce18eb170 fd8102168b33a50 272b22ec5a
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: If13e53bd5d4ace 2a53a245d74166e 4f3b1c34d4a
Closes-Bug: #1551189