Em uma ação do usuário uma vez ao dia: redefinição de 24 horas vs. redefinição da meia-noite [fechado]

Quando um usuário é capaz de executar uma ação apenas uma vez por dia, por exemplo, obter um ingresso gratuito para uma competição, há duas possibilidades que me deparei na minha experiência.

1) Reset de 24 horas

Se ele executar a ação no dia 1 às 23h45, ele poderá executar a ação novamente novamente no dia 2 ou depois das 23h45. Ele não poderá fazer 11:44 no dia 2.

2) Redefinição da meia-noite (ou qualquer horário fixo)

Independentemente da hora em que o usuário executar a ação no dia 1, assim que ele virar meia-noite e o dia 2 começar, ele poderá executá-lo novamente.

Ambos limitam o usuário a executar apenas uma ação por dia, mas geralmente encontro o método 1, que considero bastante inconveniente por dois motivos:

• Primeiro eu tenho que esperar o tempo
• e segundo, por um longo período, o registro de data e hora de minha execução será mais tarde e mais tarde, pois não poderei executar a ação exatamente nesse registro de data e hora todos os dias, apenas alguns segundos ou minutos depois.

Existe alguma razão técnica para preferir o método 1, embora na minha opinião seja uma importante desvantagem para o usuário declarada anteriormente?

Edite para especificar: estou falando especialmente de um exemplo, em que o intervalo de tempo real de 24 horas não é obviamente necessário, como no evento atual de giro livre de Theory11 , em que você recebe 1 giro grátis a cada 24 horas para ter uma chance em ganhar prêmios.

Estou surpreso, pois normalmente esperaria a redefinição da meia-noite.

No entanto, ele apresenta uma grande desvantagem, pois há mais de uma meia-noite a cada 24 horas. Você precisa escolher seu fuso horário.

Talvez seja por isso que o universal uma vez a cada 24 horas seja escolhido, você pode imaginar que a empresa talvez não queira aceitar que usuários de metade de países diferentes tenham horários locais fora da meia-noite ou, em vez de considerar que dizer "por dia" implicava meia-noite e, assim, eles alteram o marketing para "por 24 horas" e as especificações do software para corresponder

Embora eu ache isso bastante comum ver "termina às 14:00 GMT" ou similar nos dias de hoje.

Eu pensaria que o desafio de armazenar uma data da última ação para cada usuário seria mais difícil do que atribuir um fuso horário a usuários ou tipos de ação.

Editar Eu acho que vale a pena notar as diferenças entre os dois métodos

Regra 24h

• Receberei um fluxo constante de eventos, com taxa limitada a menos de 1 por 24h.
• Quando eu terminar, alguns usuários receberão menos eventos.
• Preciso armazenar todos os usuários no último evento
• Quando o horário de verão causa um dia longo ou curto, não terei 1 evento por dia
• Os seres humanos não serão capazes de acertar exatamente 24 horas, então eu naturalmente receberei menos de 1 por dia em média

Regra 1 por dia do calendário

• Recebo eventos agrupados por um período de 50h (? UTC + 14 a -12?) Atribuído a um dia do calendário
• realisticamente, ainda tenho que armazenar todos os usuários no último evento como 'dias' durante a volta
• Eu tenho um final definido de um dia em que posso dizer que todos os eventos depois de agora não estão lá .
• Preciso saber a localização do usuário para saber em que dia o evento se aplica a
• Algumas pessoas acordam muito mais cedo do que outras

1 por dia do calendário na regra UTC

• Eu recebo bons uniformes 24 horas por dia
• Eu posso balde meus eventos
• Eu sei quando o início e o fim de um dia são
• O horário de verão vai confundir as pessoas.
• Os seres humanos podem ter 1 evento por dia
• Humanos que não moram perto de Greenwich terão horários engraçados de início e fim
• Talvez eu possa fazer uma otimização inteligente e apenas armazenar uma lista de usuários que entraram? (provavelmente acabarei armazenando todos os eventos e horários dos usuários)

* O agrupamento dos eventos será super útil para vários fins de relatório. por exemplo. digamos que tenho 10 prêmios a serem ganhos a cada período de 24 horas e eles diferem com o tempo. Quantos alunos entraram no dia 10? etc

Em cima da minha cabeça:

• Pode ser mais fácil implementar a versão "24 horas desde a última ação"
• Se o usuário não executar a ação exatamente 24 horas após a última vez, eles poderão perder um período inteiro de 24 horas, porque a redefinição deve ocorrer quando eles estão dormindo ou trabalhando. Talvez o façam às 7 horas da manhã antes de sair para o trabalho e às 20 horas. No dia seguinte, eles fazem às 7h15, 7h30 e 7h45, e no último dia ficam até as 8h para realizar a ação antes de sair. No dia seguinte, eles não estão dispostos a ficar até as 8:15, portanto, apenas percam essa manhã e o façam depois de voltar para casa do trabalho às 18h, um intervalo de 34 horas. Se o resultado da ação for caro para a empresa, a economia poderá ser mais importante que o inconveniente.

Como outras respostas mencionaram, o método 24 horas é mais amigável para vários fusos horários e é tão fácil de codificar quanto você armazena o último carimbo de data / hora bem-sucedido para cada usuário.

Ele também tem o "benefício" adicional de exigir que o usuário interaja com o aplicativo todos os dias para obter todas as ações diárias. Se houver uma redefinição da meia-noite, o usuário poderá executar uma ação às 23h59 e depois novamente às 12h. Eles poderiam fazer isso todos os dias e ainda assim conseguir todas as ações. Para alguns aplicativos, o objetivo das ações diárias é permitir que o usuário interaja com o aplicativo diariamente, o que é menos ideal.

Há uma terceira alternativa que evita as armadilhas da interface do usuário de ambos, mas é um pouco mais difícil de codificar.

3) Nenhuma sequência de mais de n ações em (n-0,75) * 24 horas

Requer duas variáveis ​​para armazenar, mas permite que alguém que não está tentando abusar do sistema use sua única ação a qualquer momento durante o dia sem ter que se preocupar com fusos horários e redefinições.

Também impede que alguém use mais de 1 ação "extra".

Portanto, implemente o algoritmo necessário para armazenar a hora de início da sequência, a última hora de reprodução e o número de ações na sequência.

Manter o controle do tempo da última ação permite rejeitar duas ações muito próximas umas das outras. Você pode fazer esse limite em menos de 24 horas, porque a faixa evita rastejar no início do dia.

Uma sequência continua, desde que você faça sua ação todos os dias. Se tomar uma ação significaria que você teria mais ações do que dias na sua sequência, ela será rejeitada. Isso evita que você avance lentamente, realizando ações "extras" porque o horário de início da sequência não muda.

algum pseudo-código para implementar a verificação e acompanhar os horários:

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

Como um bônus adicional, você recebe um contador de raias, se quiser.

Sobre o seu problema com a duração de 24 horas entre as ações, algumas empresas usam uma duração de 22 horas, dessa forma os usuários ficam um pouco de folga no momento exato do dia em que a ação é necessária e ainda assim incentivam os usuários a realmente executar a ação uma vez por dia - sem 23:59 - 00:00 brecha.

Não é uma resposta, mas não tenho pontos suficientes para comentar.

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

Além das respostas acima, a redefinição da meia-noite incentiva picos de tráfego. Se a ação estiver disponível para todos os participantes em um determinado momento, haverá um incentivo para muitas pessoas tentarem a ação ao mesmo tempo. Esta é a mesma razão pela qual a maioria dos estados tem sua carteira de motorista expirar no seu aniversário em vez de em uma data fixa (EUA): o DMV não seria capaz de acompanhar se todos tivessem sua carteira de motorista expirar em 1º de janeiro.

Além disso : se um sistema de computador precisar agir uma vez por dia para um grande número de usuários, você poderá fazer a mesma pergunta, e eu normalmente o design para combinar os dois. Você pode imaginar duas tarefas cron:

1. Corra à meia-noite, encontre todos os registros, tome medidas
2. Execute a cada minuto (ou alguma frequência regular), encontre todos os registros que não agiram desde 00:00 de ontem, tome uma ação, registre que a ação foi tomada

Na prática, achei o primeiro frágil. Se uma tarefa cron for interrompida durante a execução, algum número poderá não ter a ação aplicada e um trabalho adicional poderá ser necessário para que o sistema se lembre de onde estava e continue de onde parou. Também pode causar problemas se você obter registros suficientes para que sua tarefa cron não possa processá-los todos em um prazo razoável e ela seja encerrada antes de terminar.

Este último cuida de ambas as preocupações. Ele não tem como objetivo processar tudo com exatamente 24 horas de intervalo, mas, desde que sua tarefa cron possa executar facilmente todas as ações todos os dias, elas estarão bem próximas e você garantirá que todos sejam executados a cada dia (por exemplo, você não terá as coisas se afastando lentamente por mais de 24 horas). Mais importante ainda, ele continuará facilmente de onde parou se as coisas falharem por algum motivo.

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

Os bilhetes diários de ônibus / trem da TfL (Transport for London) são válidos das 04:30 às 04:30. Faça a troca quando as pessoas estiverem dormindo. Muitas pessoas desejam usar um serviço, das 8h30 às meia-noite e meia

A redefinição da meia-noite tem uma condição específica que pode ser desejável ou prejudicial, dependendo do problema que você está tentando resolver e é: Eu posso executar a ação um dia às 11:59:58 e novamente às 00:00:01. Se o espaço problemático for algum tipo de competição, isso pode proporcionar uma vantagem injusta para as pessoas que optam por executar suas ações perto da meia-noite. A regra de redefinição de 24 horas é a única maneira de garantir uma distribuição justa das ações disponíveis, independentemente da hora do dia que alguém tem disponível para elas.

A conseqüência da redefinição de 24 horas se tornar cada vez mais tarde pode ser atenuada, fornecendo uma tolerância, por exemplo, aceitando uma solicitação de ação dentro de 15 minutos após a redefinição, desde que a ação não seja realmente registrada (ou não seja necessária) efeito) até que a redefinição ocorra. Isso introduz um pouco mais de complexidade na solução, mas não consigo pensar em nenhuma estratégia de mitigação para poder executar duas ações diárias com segundos de diferença, como no caso de redefinição à meia-noite.

Não vi ninguém mencionar o fato de que a regra das 24 horas incentiva visitas regulares de rotina. Muitos jogos têm uma recompensa de login / vitória uma vez ao dia, que é redefinida após 24 horas, porque eles preferem que você faça check-in por um curto período de tempo a cada 24 horas, em vez de duas vezes mais a cada 48 horas. Eu imagino que é semelhante para sites que oferecem brindes de ingressos.