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.
