Операція користувача один раз на день: Скидання 24 годин проти Поночі Скидання [закрито]

Коли користувач може виконати дію лише раз на день, наприклад отримати безкоштовний квиток на змагання, я зі свого досвіду зіткнувся з двома можливостями.

1) Скидання 24 годин

Якщо він виконує дію 1-го дня до 23:45, він може повторити дію лише 2-го дня, або після 11:45. Він не зможе це зробити 11:44 другого дня.

2) Поночі Скидання (або будь-який встановлений час)

Незалежно від того, в який час користувач виконує дію в перший день, як тільки настає півночі і починається 2 день, він зможе зробити це знову.

Обидва обмежують користувача у виконанні лише однієї дії на день, але я найчастіше натрапляю на метод 1, який я вважаю досить незручним з двох причин:

• Спершу треба почекати часу
• по-друге, протягом тривалого періоду часова мітка мене, яка виконує дію, стане пізніше і пізніше, оскільки я не зможу виконувати дію саме в ту часову позначку, лише через пару секунд або хвилин.

Чи є якась технічна причина, що ви віддаєте перевагу методу 1, хоча, на мою думку, важливим недоліком для користувача, заявленого заздалегідь?

Редагуйте, щоб уточнити: я особливо говорю про приклад, коли фактичний часовий проміжок 24 години очевидно не потрібен, як, наприклад, у поточному події безкоштовного віджимання Theory11 , де ви отримуєте 1 безкоштовне віджимання кожні 24 години, щоб отримати шанс. при виграші призів.

Я здивований, як зазвичай я очікував перезавантаження півночі.

Однак це має головний недолік у тому, що є щонайменше півночі кожні 24 години. Вам потрібно вибрати свій часовий пояс.

Можливо, саме тому вибирається універсальний раз на 24 години, ви можете уявити, що компанія може не захотіти визнати, що половина користувачів у різних країнах може мати не останню півночі, а точніше, ніж вони можуть вважати, що вислів "за день" мається на увазі опівночі і, таким чином, вони змінюють маркетинг на "за 24 години" та специфікацію програмного забезпечення

Хоча я думаю, що це досить поширене явище, коли "закінчується о 14:00 GMT" або подібне в ці дні.

Я б подумав, що завдання зберігання дати останньої дії для кожного користувача буде складніше, ніж завдання призначення часового поясу користувачам або типам дій.

Правка Я думаю, що варто відзначити відмінності між двома методами

Правило 24 години

• Я отримаю постійний потік подій, швидкість обмежена менше ніж 1 на 24 години.
• Коли я закінчу справу, деякі користувачі отримають менше подій.
• Мені потрібно зберігати останню подію кожного користувача
• Коли економія денного світла викликає довгий або короткий день, я не маю 1 події на день
• Люди не зможуть вдарити рівно за 24 години на крапку, тому я, звичайно, отримуватимуть менше 1 в день в середньому

1 за правило календарного дня

• Я отримую сумнівні події протягом 50-годинного (? UTC + 14 до -12?) Періоду, призначеного на календарний день
• реально мені все одно доводиться зберігати останню подію кожного користувача як "дні" на колінах
• У мене є певний кінець дня, коли я можу сказати, що всі події після цього не в день.
• Мені потрібно знати місцезнаходження користувача, щоб знати, на який день стосується їх події
• Деякі люди прокидаються набагато раніше в день, ніж інші

1 на календарний день у правилі UTC

• Я отримую гарну форму 24 години довгих днів
• Я можу вести свої події
• Я знаю, коли початок і кінець дня
• Економія літнього дня збирається збентежити людей.
• У людини може бути 1 подія на день
• Люди, які не живуть поблизу Грінвіч, матимуть смішні часи початку та закінчення
• Можливо, я можу зробити розумну оптимізацію та просто зберегти список користувачів, які ввійшли? (ймовірно, я закінчу зберігати кожну подію та час кожного користувача)

* Робоча група подій стане дуже корисною для різних цілей звітності. напр. скажіть, у мене є 10 призів, які потрібно виграти кожні 24 години, і вони різняться у часі. Скільки студентів вступило на 10 день? тощо

Вгорі голови:

• Можливо, буде легше реалізувати версію "24 години з моменту останньої дії"
• Якщо користувач не виконує дію точно через 24 години після останнього часу, то з часом він може пропустити цілий 24-годинний період, оскільки скидання має відбутися під час сну або роботи. Можливо, вони роблять це о 7 годині ранку, перш ніж виїхати на роботу, а вийти на роботу о 8 вечора. Наступного дня вони роблять це о 7:15, потім 7:30, потім 7:45, а в останній день залишаються до 8:00, щоб виконати дію безпосередньо перед від'їздом. Наступного дня вони не бажають залишатися до 8:15, тому просто пропустіть цей ранок і зробіть це після повернення додому о 18 вечора, розрив 34 години. Якщо результат акції дорогий для компанії, економія може бути важливішою, ніж незручність.

Як згадували інші відповіді, 24-годинний метод є більш сприятливим для декількох часових поясів і його так само просто кодувати, як ви просто зберігаєте останню вдалу мітку для кожного користувача.

Він також має додаткову перевагу - фактично вимагати від користувача щодня взаємодії з додатком, щоб отримувати всі щоденні дії. Якщо є скажіння скидання опівночі, користувач може зробити дію о 23:59, а потім знову о 12:00. Вони могли це робити через день і все-таки отримувати всі дії. Для деяких додатків мета щоденних дій полягає в тому, щоб користувач щодня спілкувався з додатком, тому це менш ідеально.

Є третя альтернатива, яка дозволяє уникнути підводних каменів обох інтерфейсів, але їх трохи важче кодувати.

3) Немає смуг більш ніж n дій за (n-0,75) * 24 години

Для зберігання потрібні дві змінні, але це дозволяє тим, хто не намагається зловживати системою, використовувати їх одну дію в будь-який час протягом дня, не турбуючись про часові пояси та скидання.

Це також заважає комусь використовувати більше 1 «зайвої» дії.

Тож реально реалізуйте алгоритм, який вам потрібно буде зберігати час початку смуги, час останнього відтворення та кількість дій у вашій смузі.

Відстеження часу останньої дії дозволяє відхилити дві дії, які знаходяться занадто близько один до одного. Цей обмеження можна зробити менше ніж на 24 години, оскільки смуга запобігає повзанню раніше дня.

Смуга триває до тих пір, поки ви щодня приймаєте свої дії. Якщо вжити заходів означатиме, що у вас буде більше дій, ніж днів, то її відхилять. Це запобігає повільному повзанню вперед, упаковці в "зайві" дії, оскільки час початку вашої смуги не змінюється.

деякий псевдо-код для здійснення перевірки та відстеження часу:

//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;
}

Як додатковий бонус, ви отримуєте лічильник смуг, якщо ви хочете його.

Щодо вашої проблеми з тривалістю 24 години між діями, деякі компанії замість цього використовують 22-годинну тривалість. Таким чином, користувачі отримують трохи свободи в точний момент дня, коли необхідна дія, і все ж отримують спонукання користувачів до дійсної дії раз на день -не 23:59 - 00:00 лазівку.

Не відповідь, але у мене недостатньо балів для коментарів.

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

На додаток до вищезазначених відповідей, опівночі скидання заохочує спливи руху. Якщо акція стане доступною для всіх учасників у певний час, тоді багато людей будуть стимулом одночасно робити спробу. Це та сама причина, чому в більшості штатів термін дії посвідчення водіїв закінчується в день народження, а не на встановлену дату (США): DMV не зможе продовжувати роботу, якщо термін дії посвідчення водія закінчується 1 січня.

Невелика сторона : якщо комп'ютерній системі потрібно вживати заходів один раз на день для великої кількості користувачів, ви можете задати одне і те ж питання, і я, як правило, проектую це поєднання обох. Ви можете уявити собі два завдання:

1. Біжіть опівночі, знайдіть усі записи, прийміть дії
2. Запускайте кожну хвилину (або якусь регулярну частоту), знайдіть усі записи, які не були вжиті з 00:00 вчора, вживайте заходів, записуйте, що дія було зроблено

На практиці я виявив колишнього крихким. Якщо під час запуску завдання cron зламається, деяка кількість може не застосовувати дії, і може знадобитися додаткова робота, щоб запам'ятати, де вона була, і забрати, де вона зупинилася. Це також може спричинити проблеми, якщо ви отримаєте достатньо записів про те, що ваше завдання Cron не може обробити їх усі в розумний термін, і він закінчується перед закінченням.

Останній піклується про обидва ці проблеми. Це не спрямоване на те, щоб все оброблялося рівно за 24 години, але поки ваша робота із кроном може легко виконувати всі дії кожного дня, вони будуть досить близькими, і ви гарантуєте, що кожен буде запущений кожного фактичного дня (тобто у вас не буде, що речі повільно розходяться більше ніж на 24 години). Найголовніше, що він легко підбере там, де він зупинився, якщо щось зірветься з якихось причин.

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

Щоденні квитки на автобус / поїзд у TfL (Транспорт для Лондона) діють з 4:30 до 4:30 ранку. Робіть перемикач, коли люди сплять. Дуже багато людей захочуть скористатися послугою, сказати з 8:30 до години ночі

Повторне скидання має конкретний стан, який може бути бажаним або згубним, залежно від того, яку проблему ви намагаєтеся вирішити, а це: я можу виконати дію одного дня о 11:59:58 і знову о 00:00:01. Якщо проблемний простір є якоюсь конкуренцією, це може надати несправедливій перевазі людям, які вирішили виконувати свої дії близько півночі. Правило скидання 24 години - це єдиний спосіб забезпечити справедливий розподіл доступних дій незалежно від того, в який час доби хтось їм доступний.

Наслідком 24-годинного скидання, що стає пізніше і пізніше, можна пом'якшити, передбачивши допуск, наприклад, прийнявши запит на дію протягом 15 хвилин після скидання, який відбувся до тих пір, поки дія фактично не записано (або не відбудеться ефект), поки не відбудеться скидання. Це вводить трохи більше складності в рішення, але я не можу придумати жодної стратегії пом'якшення наслідків для того, щоб мати можливість робити дві щоденні дії за секунди, як у випадку скидання опівночі.

Я не бачив жодного згадування того факту, що правило 24 години заохочує звичайні регулярні відвідування. У багатьох іграх є нагорода за вхід / перемогу один раз на день, яка скидається через 24 години, тому що вони швидше заїжджатимуть на короткий час кожні 24 години, а не вдвічі кожні 48 годин. Я думаю, це схоже на веб-сайти, що розміщують роздачу квитків.