New EOT date isn't what expected

I’ve got a question regarding how s2member calculates the auto-eot for a user when they renew/upgrade before their current membership level has expired.

Case in point:

We have a user who has an auto-eot that was manually setup (i.e. we entered the date in the auto-eot field) when we started our site to have an expiry of August 01, 2012 12:00AM UTC

This customer purchased a renewal and their new expiry date was set to July 28, 2013.

The membership levels are being sold as a 12 month non recurring subscription.

So… the EOT is close to what’s expected but still a few days off of what we do expect which is August 01, 2013.

Is there a reason why this is happening? Would the fact that this year is a leap year have something to do with it?

Hi Darren.

Did the user pay a few days before Aug 1st? If so, it seems that the year was calculated from the date it was paid, disregarding the days he had left from his last payment.

That’s the behavior with subscriptions, if the user starts the subscription again, then the days left from the previous one will be lost. If you’re using subscriptions, then you’ll need to add some PHP code to your button to calculate the time he has left and add it to the new time he’s paying for.

With buy-now transactions, though, you can have the new paid time be added after the time he had left. You’ll find the setting at the bottom of the EOT panel. [hilite path]Dashboard -› s2Member® -› PayPal® Options -› Automatic EOT Behavior[/hilite]

Fixed-Term Extensions ( auto-extend )?
This setting will only affect Buy Now transactions for fixed-term lengths. By default, s2Member will automatically extend any existing EOT Time that a Customer may have.

We’re working to improve this in the new s2Member.

This is a non-recurring subscription (acting as a buy now) – and I’m aware of the Fixed-Term Extensions (auto-extend) feature which is enabled.

At first I was thinking what you suggested was happening too, but the customer made the purchase two days ago (July 20) so IF that was the case then there would be quite a few more days missing from their new expiry date (as given above).

I just posted here to see if you had a quick answer for why this may be happening. No worries, I’ll just dive into the code and see if I can figure it out myself. If I can, I’ll post back here so you guys can use whatever I fine in improving the EOT system.

BTW, we’ve got s2member working quite well on our site (EventEspresso.com) integrated with bbPress and a lot of customization :)

This is a non-recurring subscription (acting as a buy now) – and I’m aware of the Fixed-Term Extensions (auto-extend) feature which is enabled.

Even if your subscription is for a single term, it’s still a subscription, not a buy-now, so the Fixed-Term Extensions setting won’t apply to it.

At first I was thinking what you suggested was happening too, but the customer made the purchase two days ago (July 20) so IF that was the case then there would be quite a few more days missing from their new expiry date (as given above).

I just posted here to see if you had a quick answer for why this may be happening. No worries, I’ll just dive into the code and see if I can figure it out myself. If I can, I’ll post back here so you guys can use whatever I fine in improving the EOT system.

Ah okay, got it.

BTW, we’ve got s2member working quite well on our site (EventEspresso.com) integrated with bbPress and a lot of customization :)

That’s great! :)

That’s a nice events plugin you have there, from what I’ve heard. Nice job!

(I posted this earlier but for some reason it disappeared? Maybe I was just previewing it and forgot to actually post).

Okay, now I know what happened.

In the file

utils-time.inc.php

around line 189 is the calculation of the eot days and time using the eotper:

list ($num, $span) = preg_split ("/ /", $eotper, 2);
/**/
$days = 0; /* Days start at 0. */
/**/
if (is_numeric ($num) && !is_numeric ($span))
        {
        $days = ($span === "D") ? 1 : $days;
        $days = ($span === "W") ? 7 : $days;
        $days = ($span === "M") ? 30 : $days;
        $days = ($span === "Y") ? 365 : $days;
    }
/**/
$eot_days = (int)$num * (int)$days;
$eot_time = $eot_days * 86400;

We currently have the non-recurring subscription set to 12 months. With the calculation above, 12 * 30 = 360 days. 1 day is added by s2member later so that gives me 4 days off of the usual 365 days which pretty much matches our “missing days”. To fix this we’d have to change our non-recurring subscription to 1 year instead of 12 months.

Subscriptions can be confusing can’t they :) We have our purchases setup for buy now fixed term.

Great. Glad you found the reason behind it. :)

I don’t know if that’s how PayPal calculates terms and s2Member is just following their standard.

When it’s a month or a year, it should be probably calculated with a calendar instead of a set number of days.