Membership expiration #1513
Membership expiration #1513
Conversation
…hip where estimated expiration date is in the past
Use events' extras counting introduced in #1517.
| new_expiry_date = datetime.date( | ||
| started_year, 9, 16) + datetime.timedelta(days=365*length_of_fos) | ||
| # Expiry dates in the past sets the expiry date to next september | ||
| if new_expiry_date < datetime.date.today(): |
There was a problem hiding this comment.
Use django.utils.timezone instead of datetime.datetime. :-) That takes care of all timezone stuff (and DST/Summer time).
There was a problem hiding this comment.
I can see how that is better on a general basis, but is it really necessary here when it's only dealing with dates? Even if it gets set off by one day due to time-differences that wouldn't be that bad, would it?
There was a problem hiding this comment.
https://docs.djangoproject.com/en/1.9/topics/i18n/timezones/#naive-and-aware-datetime-objects
This matters mostly for datetime objects, so you're right in the fact that it's less important for date. Anywho, it's better practice to do today = timzone.now().date.today() and work with today rather than doing datetime.date.today() every time you need the variable (the same goes for datetime.date.today() for that matter). :-)
So yes, I was a bit too quick to respond in this case.
…into membership-expiration
…iable to make code more readible.
Fix #1400
Sets the expiration date for membership-applications where estimated expiry is in the past to upcoming September.