En una acción de usuario una vez al día: restablecimiento de 24 horas frente a restablecimiento de medianoche [cerrado]

Cuando un usuario puede realizar una acción solo una vez al día, por ejemplo, obtener un boleto gratis para una competencia, hay dos posibilidades que encontré en mi experiencia.

1) Restablecimiento de 24 horas

Si realiza la acción el día 1 a las 11:45 p.m., solo puede realizar la acción nuevamente el día 2 a partir de las 11:45. No podrá hacerlo 11:44 el día 2.

2) Restablecimiento de medianoche (o cualquier hora fija)

No importa a qué hora el usuario realiza la acción el día 1, tan pronto como sea medianoche y comience el día 2, podrá volver a hacerlo.

Ambos limitan al usuario a realizar solo una acción al día, pero a menudo encuentro el método 1, que creo que es bastante inconveniente por dos razones:

• Primero tengo que esperar el tiempo
• y segundo durante un período de tiempo prolongado, la marca de tiempo de mí realizando la acción será cada vez más tarde, ya que no podré realizar la acción exactamente en esa marca de tiempo todos los días, solo un par de segundos o minutos más tarde.

¿Hay alguna razón técnica por la que uno preferiría el método 1, aunque en mi opinión la desventaja importante para el usuario mencionada anteriormente?

Editar, para especificar: Estoy hablando especialmente de un ejemplo, donde el intervalo de tiempo real de 24 horas obviamente no es necesario, como en el evento actual de giros gratis de Theory11 , donde obtienes 1 giro gratis cada 24 horas para tener la oportunidad en ganar premios.

Me sorprende, ya que normalmente esperaría el reinicio de medianoche.

Sin embargo, viene con una gran desventaja, ya que hay más de una medianoche cada 24 horas. Debes elegir tu zona horaria.

Tal vez es por eso que se elige la opción universal una vez cada 24 horas, se puede imaginar que la compañía podría no querer aceptar que los usuarios que están en la mitad de países diferentes podrían tener horas de finalización local que no sean de medianoche, o en lugar de considerar que decir "por día" implicaba medianoche y así cambian el marketing a "por 24h" y las especificaciones del software para que coincidan

Aunque creo que es bastante común ver que "termina a las 2pm GMT" o similar en estos días.

Pensé que el desafío de almacenar una última fecha de acción para cada usuario sería más difícil que asignar una zona horaria a usuarios o tipos de acción.

Editar Creo que vale la pena señalar las diferencias entre los dos métodos

Regla 24h

• Obtendré un flujo constante de eventos, tasa limitada a menos de 1 por 24h.
• Cuando termine la cosa, algunos usuarios obtendrán menos eventos.
• Necesito almacenar el último evento de cada usuario
• Cuando el horario de verano causa un día largo o corto, no tendré 1 evento por día
• Los humanos no podrán llegar exactamente a las 24 h en punto, por lo que, naturalmente, obtendré menos de 1 por día en promedio

1 por regla de día calendario

• Recibo eventos agrupados durante un período de 50h (? UTC + 14 a -12?) Asignado a un día calendario
• de manera realista, todavía tengo que almacenar todos los usuarios del último evento como 'días' en la vuelta
• Tengo un final definitivo del día donde puedo decir todos los eventos después de ahora no están en el día.
• Necesito saber la ubicación del usuario para saber a qué día se aplica su evento
• Algunas personas están despiertas mucho antes en el 'día' que otras

1 por día calendario en la regla UTC

• Me pongo buen uniforme 24h días largos
• Puedo poner en mis eventos
• Sé cuándo es el comienzo y el final de un día.
• El horario de verano confundirá a las personas.
• Los humanos pueden tener 1 evento por día
• Los humanos que no viven cerca de Greenwich tendrán tiempos divertidos de inicio y finalización
• ¿Quizás pueda hacer una optimización inteligente y simplemente almacenar una lista de usuarios que han ingresado? (probablemente terminaré almacenando cada evento y hora de los usuarios)

* Agrupar los eventos será súper útil para varios propósitos de informes. p.ej. Digamos que tengo 10 premios que ganar cada 24 horas y que difieren con el tiempo. ¿Cuántos estudiantes ingresaron el día 10? etc.

La parte superior de mi cabeza:

• Puede ser más fácil implementar la versión "24 horas desde la última acción"
• Si el usuario no realiza la acción exactamente 24 horas después de la última vez, eventualmente puede perder un período completo de 24 horas porque el restablecimiento debe ocurrir cuando está dormido o trabajando. Tal vez lo hacen a las 7 am antes de irse a trabajar, y se van a trabajar a las 8 pm. Al día siguiente lo hacen a las 7:15, luego a las 7:30, luego a las 7:45, y el último día permanecen hasta las 8:00 para realizar la acción justo antes de partir. Al día siguiente, no están dispuestos a quedarse hasta las 8:15, así que solo falta esa mañana y hazlo después de regresar a casa del trabajo a las 6 pm, un lapso de 34 horas. Si el resultado de la acción es costoso para la empresa, el ahorro podría ser más importante que el inconveniente.

Como han mencionado otras respuestas, el método de 24 horas es más amigable para múltiples zonas horarias, y es tan fácil de codificar, como simplemente almacena la última marca de tiempo exitosa para cada usuario.

También tiene el "beneficio" adicional de requerir que el usuario interactúe con la aplicación todos los días para obtener todas las acciones diarias. Si hay un reinicio de medianoche, entonces un usuario puede realizar una acción a las 11:59 p.m. y luego nuevamente a las 12:00 a.m. Podrían hacer esto cada dos días y aún así obtener todas las acciones. Para algunas aplicaciones, el propósito de las acciones diarias es lograr que el usuario interactúe con la aplicación a diario, por lo que esto es menos ideal.

Hay una tercera alternativa que evita las dificultades de la interfaz de usuario de ambos, pero es un poco más difícil de codificar.

3) Sin rayas de más de n acciones en (n-0.75) * 24 horas

Requiere dos variables para almacenar, pero permite que alguien que no está tratando de abusar del sistema use su única acción en cualquier momento durante el día sin tener que preocuparse por las zonas horarias y los reinicios.

También evita que cualquier persona use más de 1 acción "extra".

Así que implemente el algoritmo que necesitaría para almacenar el tiempo de inicio de la racha, el último tiempo de juego y la cantidad de acciones en su racha.

Hacer un seguimiento del último tiempo de acción le permite rechazar dos acciones que están demasiado juntas. Sin embargo, puede establecer este límite en menos de 24 horas porque la racha evita que se arrastre más temprano en el día.

Una racha continúa mientras actúes todos los días. Si tomar una acción significa que tendría más acciones que días en su racha, entonces se rechaza. Esto evita avanzar lentamente, lo que implica acciones "adicionales" porque el tiempo de inicio de su racha no cambia.

algún pseudocódigo para implementar la verificación y rastrear los tiempos:

//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 un bono adicional, obtienes un contador de rachas, si quieres uno.

Acerca de su problema con la duración de 24 horas entre acciones, algunas empresas en su lugar usan una duración de 22 horas, de esta manera los usuarios obtienen un poco de margen de maniobra en el momento exacto del día en que se requiere la acción y aún así animan a los usuarios a realizar la acción. una vez al día -no 23:59 - 00:00 escapatoria.

No es una respuesta, pero no tengo suficientes puntos para comentar.

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

Además de las respuestas anteriores, el reinicio de medianoche fomenta oleadas de tráfico. Si la acción se pone a disposición de todos los participantes en un momento determinado, entonces habrá un incentivo para que muchas personas intenten la acción al mismo tiempo. Esta es la misma razón por la cual la mayoría de los estados vencen su licencia de conducir en su cumpleaños en lugar de una fecha fija (EE. UU.): El DMV no podría mantenerse al día si todos vencieran su licencia de conducir el 1 de enero.

Pequeño aparte : si un sistema informático necesita tomar medidas una vez al día para una gran cantidad de usuarios, puede hacer la misma pregunta, y normalmente la diseño para que sea una combinación de ambos. Podrías imaginar dos tareas cron:

1. Corre a medianoche, encuentra todos los registros, toma medidas
2. Ejecute cada minuto (o alguna frecuencia regular), encuentre todos los registros que no hayan tomado medidas desde las 00:00 de ayer, tome medidas, registre que se tomaron medidas

En la práctica, he encontrado que el primero es frágil. Si una tarea cron se rompe mientras se ejecuta, es posible que algún número no tenga la acción aplicada, y puede ser necesario un trabajo adicional para que el sistema recuerde dónde estaba y retome donde lo dejó. También puede causar problemas si obtiene suficientes registros para que su tarea cron no pueda procesarlos en un límite de tiempo razonable, y se apaga antes de finalizar.

Este último se ocupa de ambas preocupaciones. No tiene como objetivo que todo se procese exactamente con 24 horas de diferencia, pero siempre que su tarea cron pueda ejecutar fácilmente todas las acciones cada día, estarán bastante cerca y garantizará que todos se ejecuten en cada día real (es decir, no tendrás las cosas lentamente separadas por más de 24 horas). Sin embargo, lo más importante es que continuará fácilmente donde lo dejó si las cosas se descomponen por alguna razón.

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

Los boletos diarios de autobús / tren en TfL (Transporte para Londres) son válidos de 4:30 a.m. a 4:30 a.m. Haga el cambio cuando la gente esté dormida. Mucha gente querrá usar un servicio, digamos de 8:30 a una hora pasada la medianoche

El reinicio de medianoche tiene una condición específica que podría ser deseable o perjudicial, dependiendo del problema que intente resolver y es: puedo realizar la acción un día a las 11:59:58 y nuevamente a las 00:00:01. Si el espacio problemático es algún tipo de competencia, esto podría impartir una ventaja injusta a las personas que eligen realizar sus acciones cerca de la medianoche. La regla de reinicio de 24 horas es la única forma de garantizar una distribución justa de las acciones disponibles, independientemente de la hora del día en que alguien tenga disponible.

La consecuencia del restablecimiento de 24 horas cada vez más tarde puede mitigarse al proporcionar una tolerancia, por ejemplo, aceptar una solicitud de acción dentro de los 15 minutos posteriores al restablecimiento, siempre que la acción no se registre realmente (o no tome efecto) hasta que se produzca el restablecimiento. Esto introduce un poco más de complejidad en la solución, pero no puedo pensar en ninguna estrategia de mitigación para poder tomar dos acciones diarias separadas por segundos como en el caso de reinicio de medianoche.

No he visto a nadie mencionar el hecho de que la regla de las 24 horas fomenta las visitas regulares de rutina. Muchos juegos tienen una recompensa de inicio de sesión / victoria una vez al día que se restablece después de 24 horas porque prefieren que se registre por un corto tiempo cada 24 horas en lugar de por el doble cada 48 horas. Me imagino que es similar para los sitios web que alojan sorteos de boletos.