XF 2.1 24h upgrade doesn't count properly

Fattycakez1

Active member
3vpEpbc.png


So i have a 24h upgrade which is supposed to end in 24h right?


start_date 1595693633 = Saturday, July 25, 2020 6:13:53 PM GMT+02:00

end_date 1595718088 = Sunday, July 26, 2020 1:01:28 AM GMT+02:00

Which is like 7 hours from start date, How is that 24h?

I'm missing something or just bad at math or what's going on.
 
Solution
There's a little bit of a misunderstanding related to some of the replies here. As you can see in the first post our time format is epoch time/unix time. This means we essentially store times as a number of seconds.

This is relevant because basically it does not matter what time unit you specify we convert it back to seconds. 1 hour is 3,600 seconds, 1 day is 86,400 seconds, 1 year is 365 * 86,400 seconds.

Crucially, if we did support hours then 24 hours would also come out as 86,400 seconds.

I have to say it would be incredibly peculiar if, by design, 1 day was somehow not the same as 24 hours. While a good theory, that would absolutely never be the case.

But all that being said, I think I know what has happened here.

I think this...
2 days seems to do the trick but the only issue is it says $5.66 for 2 day


Is there's a way to manually change the upgrade price description through templates or something? Like make it say $5.66 for 1 day but it's actually 2 days.
 
So there may be a related issue / bug with this that I encountered but never mentioned because I didn't get around to troubleshooting.

I had a user upgrade that was listed as purchased user upgrade in the purchased upgrade section on their profile, and I believe there's an 'expires' date and time published next to it.

Once you get close to the expiry date it gives you an exact time. But I'm pretty sure the active upgrade stayed present on the user upgrade page long after the published expiry time. I say long, I mean some time in the following 24 hours, similar to the OP.

I never bothered looking into it more though as the upgrades on the site in question are 6 months and 12 months, so no big deal. But to be precise I would expect it to clear from that screen at the exact time set if it gives one.
 
There's a little bit of a misunderstanding related to some of the replies here. As you can see in the first post our time format is epoch time/unix time. This means we essentially store times as a number of seconds.

This is relevant because basically it does not matter what time unit you specify we convert it back to seconds. 1 hour is 3,600 seconds, 1 day is 86,400 seconds, 1 year is 365 * 86,400 seconds.

Crucially, if we did support hours then 24 hours would also come out as 86,400 seconds.

I have to say it would be incredibly peculiar if, by design, 1 day was somehow not the same as 24 hours. While a good theory, that would absolutely never be the case.

But all that being said, I think I know what has happened here.

I think this issue is exclusively related to manually upgrading a user, i.e. this form:

1595796220877.webp

This form somewhat ignores the length values set when you create the upgrade. It does use that to set a default, but of course it isn't particularly precise because it only supports the date and it doesn't support a particular time.

The same behaviour would occur even if you somehow had a way of setting the expiry time as "24 hours".

So the next question is - are you planning to upgrade a lot of users manually? If not, and this was just for testing purposes, you can mostly ignore it as a design issue due to how our manual upgrade form works. Upgrades done via a normal purchase will get the full 1 day / 24 hours as you would expect.
 
Solution
There's a little bit of a misunderstanding related to some of the replies here. As you can see in the first post our time format is epoch time/unix time. This means we essentially store times as a number of seconds.

This is relevant because basically it does not matter what time unit you specify we convert it back to seconds. 1 hour is 3,600 seconds, 1 day is 86,400 seconds, 1 year is 365 * 86,400 seconds.

Crucially, if we did support hours then 24 hours would also come out as 86,400 seconds.

I have to say it would be incredibly peculiar if, by design, 1 day was somehow not the same as 24 hours. While a good theory, that would absolutely never be the case.

But all that being said, I think I know what has happened here.

I think this issue is exclusively related to manually upgrading a user, i.e. this form:

View attachment 231394

This form somewhat ignores the length values set when you create the upgrade. It does use that to set a default, but of course it isn't particularly precise because it only supports the date and it doesn't support a particular time.

The same behaviour would occur even if you somehow had a way of setting the expiry time as "24 hours".

So the next question is - are you planning to upgrade a lot of users manually? If not, and this was just for testing purposes, you can mostly ignore it as a design issue due to how our manual upgrade form works. Upgrades done via a normal purchase will get the full 1 day / 24 hours as you would expect.

Awesome thank you so much for clarifying this was makin me go nuts trying to figure it out. I do plan to manual upgrade some people but i guess im gonna have to modify it through db but thanks
 
Good info Chris. My example was probably from a manual upgrade test. Although I did do some test upgrades using the stripe test card data, and some tests with real money coming from my actual bank account. Which one resulted in the issue, I'm not sure.

With regards to how many manual upgrades may get applied. My client currently charges their users once offline every 6 -12 months at precise times twice a year (likely to change once they switch over to the XF membership system). We've now missed the July payment, so if he decides to go live in August, we'll need to manually upgrade all the users that have already paid directly by BT for the service in a non XF-Related way this month.

Although this still isn't a massive deal in my case if it's only +-24 hours considering the overall sub length. While it's only a small issue, it's still a bit weird if they go to resubscribe on the last day of their manual sub and see an active subscription hours after the displayed expiry time.

Don't spend any time on it because of my use case though if you don't think it needs it, because it sounds like it won't be an issue after the first real user initiated billing cycle.
 
Good info Chris. My example was probably from a manual upgrade test. Although I did do some test upgrades using the stripe test card data, and some tests with real money coming from my actual bank account. Which one resulted in the issue, I'm not sure.

With regards to how many manual upgrades may get applied. My client currently charges their users once offline every 6 -12 months at precise times twice a year (likely to change once they switch over to the XF membership system). We've now missed the July payment, so if he decides to go live in August, we'll need to manually upgrade all the users that have already paid directly by BT for the service in a non XF-Related way this month.

Although this still isn't a massive deal in my case if it's only +-24 hours considering the overall sub length. While it's only a small issue, it's still a bit weird if they go to resubscribe on the last day of their manual sub and see an active subscription hours after the displayed expiry time.

Don't spend any time on it because of my use case though if you don't think it needs it, because it sounds like it won't be an issue after the first real user initiated billing cycle.
I just tried and made a test payment through stripe and bought a 24h upgrade

and it works completely fine as chris stated it's only related to manual upgrades

This is the date i got when i purchased normally through stripe 1595886343 which is a day from now.
 
Top Bottom