Ytukyg

Off the top of my head:

• It may be easier to implement the "24-hours since last action" version


• If the user does not perform the action exactly 24 hours after the last time, then eventually they may miss a whole 24-hour period because the reset must happen when they are asleep, or working. Perhaps they do it at 7 am before leaving for work, and leave for work at 8 pm. The next day they do it at at 7:15, then 7:30, then 7:45, and on the last day stay until until 8:00 to perform the action just before leaving. The next day they are not willing to stay until until 8:15, so just miss that morning and do it after returning home from work at 6 pm, a gap of 34 hours. If the result of the action is expensive for the company the saving might be more important than the inconvenience.

As other answers have mentioned, the 24hr method is more friendly to multiple time zones, and is just as easy to code, as you just store the last successful timestamp for each user.

It also has the added "benefit" of actually requiring the user to interact with the app each day to get all of daily actions. If there is say a midnight reset, then a user may do an action at 11:59PM, and then again at 12:00AM. They could do this every other day and still get all the actions. For some apps the purpose of daily actions is to get the user to interact with the app on a daily basis so this is less ideal.

There's a third alternative that avoids the UI pitfalls of both, but is a bit harder to code.

3) No streaks of more than n actions in (n-0.75)*24 hours

It does require two variables to store, but it allows someone who's not trying to abuse the system to use their one action at anytime during their day without having to worry about timezones and resets.

It also prevents anyone from using more than 1 "extra" action.

So actually implement the algorithm you'd need to store the start time of the streak, the last play time, and the number of actions in your streak.

Keeping track of the last action time allows you to reject two actions that are too close together. You can make this limit less than 24 hours though because the streak prevents creeping earlier in the day.

A streak keeps going as long as you take your action every day. If taking an action would mean you'd have more actions than days in your streak then it gets rejected. This prevents slowly creeping forward, packing in "extra" actions because the start time of your streak doesn't change.

some pseudo code to implement the check and track the times:

//precondition: streakStart and  lastAction are initialized as in the far past

//              streakCount is initialized as 0

graceHours=18;

checkAllowed(currentTime,&streakStart,&streakCount, &lastAction){

    diffhours=hoursDifferent(lastAction,currentTime);

    if(diffhours< 24 - graceHours){

        return false;

    }

    diffhours=hoursDifferent(streakStart,currentTime);

    if(diffhours <= 24*streakCount - graceHours){

        return false;

    }

    if(diffhours > 24*(streakCount+2)-graceHours){

        streakStart=currentTime;

        streakCount=0;

    }

    streakCount++;

    lastActionTime=currentTime;

    return true;

}

As an added bonus, you get a streak counter, if you want one.

About your problem with the 24h duration between actions, some companies instead use a 22h duration, this way the users get a bit of leeway on the exact moment of the day where the action is required and still get to encourage users to actually perform the action once per day -no 23:59 - 00:00 loophole.

Not an answer but I don't have enough points to comment.

tl/dr: 24 hour resets are the lazy man's way of minimizing load spikes

In addition to the above answers, the midnight-reset encourages surges of traffic.
If the action becomes available to all participators at a particular time, then there is going to be an incentive for many people to attempt the action at the same time. This is the same reason why most states have your drivers license expire on your birthday instead of on a fixed date (USA): the DMV wouldn't be able to keep up if everyone had their driver's license expire on January 1st.

Small Aside: if a computer system needs to take action once a day for a large number of users, you can ask the same question, and I typically design it to be a combination of both. You could imagine two cron tasks:

1. Run at midnight, find all records, take action


2. Run every every minute (or some regular frequency), find all records that haven't taken action since 00:00 yesterday, take action, record that action was taken

In practice I have found the former to be brittle. If a cron task breaks while running then some number may not have the action applied, and additional work may be needed for the system to remember where it was and pick up where it left off. It can also cause problems if you get enough records that your cron task can't process them all in a reasonable time limit, and it gets shut down before finishing.

The latter takes care of both of those concerns. It doesn't aim to get everything processed exactly 24 hours apart, but as long as your cron task can easily run through all actions each day, they will be pretty close and you'll guarantee that everyone gets run on each actual day (i.e. you won't have things slowly drifting apart by more than 24 hours). Most importantly though, it will easily pick up where it left off if things break down for some reason.

https://www.youtube.com/watch?v=hoMO1yYC7pQ

Daily bus/train tickets at TfL (Transport for London) are valid from 4:30am to 4:30am. Do the switch when people are asleep. Plenty of people will want to use a service say from 8:30 to an hour past midnight

The midnight reset has a specific condition that could be either desirable or detrimental, depending on what problem you are trying to solve and that is: I can perform the action one day at 11:59:58 and again at 00:00:01. If the problem space is any kind of competition, this could impart an unfair advantage to people choosing to perform their actions close to midnight. The 24-hour reset rule is the only way to ensure a fair distribution of available actions regardless of what time of day someone has available to them.

The consequence of the 24-hour reset becoming later and later can be mitigated by providing for a tolerance, for example accepting an action request within 15 minutes of the reset occurring so long as the action isn't actually recorded (or doesn't take effect) until the reset occurs. This introduces a bit more complexity into the solution, but I can't think of any mitigation strategy for being able to take two daily actions seconds apart as in the midnight reset case.

I haven’t seen anyon mention the fact that the 24 hour rule encourages routine regular visits. A lot of games have a once a day login/victory reward that resets after 24 hours because they would rather you check in for a short time every 24 hours rather than for twice as long every 48 hours. I’d imagine it’s similar for websites hosting ticket giveaways.