Validación de "fecha de nacimiento": ¿hasta dónde/cuánto llegarías?

Question

Soy bastante anal sobre la validación de formularios. Entonces, al crear un validador para un campo de "datos de nacimiento" (DOB) en uno de mis proyectos actuales para un formulario de solicitud de empleo (la plataforma/idioma es neutral en este contexto), quería algo para evitar las entradas 'punky'.

Utilicé un selector de fechas y restringí la fecha máxima para ser XX años desde el día actual. XX tienen sentido para este escenario ya que cualquier persona más joven no debería incluso solicitar el puesto.

El mensaje de error de validación es: Parece demasiado joven para el trabajo.

Entonces empecé a ser aventurero. ¿Qué tal si?

Si la fecha de nacimiento es hace más de 120 años, mensaje: "¡No puedes ser tan viejo!"

Si la fecha de nacimiento es futura, mensaje: "Debes estar bromeando, ¡todavía no has nacido!"

Al final, implementé sin los 2 últimos, demasiado descarado para mi cliente sin sentido.

Me gustaría saber qué tan lejos/cuánto ustedes van a validar los campos de DOB para una buena usabilidad (o humor)?

Del mismo modo para fechas como "Fecha de matrimonio", "Año de graduación", etc ...

PS: Cuando estaba a punto de enviar este mensaje, hay una advertencia sobre ello en el cuadro de texto del título: "El la pregunta que hace parece subjetiva y es probable que se cierre ". Dedos cruzados.

Para agregar: Estoy bastante sorprendido de que a algunos/la mayoría de los muchachos no les preocupe demasiado la validación. Repito uno de mis comentarios aquí:

Si el usuario ingresó la fecha erróneamente (algo muy obvio) ya sea por intención o por error; ese es uno de los propósitos de los validadores para atraparlo. Cuando los datos entran en el sistema, el propietario del sitio solo sabe que la entrada es incorrecta, él/ella no sabría el valor real sin preguntarle al usuario. Si este campo es muy importante, no será un escenario bonito.

Answer 1

Piense en las veces que ha llenado los formularios. ¿Cuántas veces se ha sentido frustrado porque un programador "excesivamente inteligente" insertó alguna "validación" que resultó ser incorrecta para su circunstancia? Yo digo, confíe en el usuario. Ahora que lo pienso, a medida que pasa el tiempo, supongo que la gente vive más tiempo y entra en la red a edades más tempranas, de todos modos. : P

Answer 2

fecha válido: compruebe
Fecha no en el futuro: tal vez (Yo trato con aplicaciones médicas, así que supongo que podría estar tratando a los bebés por nacer)
La fecha no tienen más de 120 años: probablemente

estoy no es un gran admirador de la sobreingeniería de estas cosas, especialmente si un error del usuario es relativamente inofensivo y se puede detectar y solucionar fácilmente. Así es como me acerco a él de todos modos.

Answer 3

ser un perfeccionista Me quedaría aquí de 150: D

tan bajo como lo más probable es, la gente ha superado el 120, y que saben lo que deberá sucede en los próximos 30 años: D

i no obstante, no lo considero tan importante ...

Answer 4

no olvide que también puede advertir al usuario de valores poco probables. En la mayoría de los casos, un error tipográfico es más probable que deliberadamente ser incómodo.

Así que para su aplicación, tal vez algo como esto:

• Edad < min. edad solicitante - Error
• edad> común la edad de jubilación - advertencia
• edad> esperanza de vida - Error

Answer 5

fecha válida:

voy a ir a la extensión de comprobar si existe esta fecha o no. es decir, el año bisiesto 29a febrero y así sucesivamente

Fecha en el futuro:

que suelen comprobar la edad (este año - DOB dado) y debe ser al menos de cierta edad para inscribirse.

Fecha mayores de 120 años o no:

no voy a comprobar. 200 años sería un límite más seguro? (en caso de que un hombre de 121 años desee usar la computadora *chuckles*)

Answer 6

El humor es algo bastante subjetivo y muy específico del proyecto, por lo que es un poco difícil responder en ese sentido. Una vez dicho esto, si la aplicación admite un proceso formal, como la solicitud de un trabajo, probablemente me equivoque por precaución y lo mantengo bastante real.

En cuanto a la validación, creo que el esfuerzo para que vaya aquí debe ser proporcional al impacto de los datos no válidos que se abren paso desde la interfaz de usuario. Volviendo al formulario de solicitud de empleo, imagino que habrá un proceso de revisión humana en algún momento, por lo que el riesgo de datos no válidos es mínimo si los datos se ingresaron de forma incorrecta o intencional.

Si le preocupan las entradas "punky" o bot impulsadas, utilice Captcha. Habiendo dicho todo eso, creo que estás bastante seguro con las reglas de validación que has usado.

Answer 7

Todo depende de la aplicación. Una aplicación de línea de negocio (LOB) para el procesamiento de pedidos es muy diferente al seguimiento de datos históricos o futuros.

Se puede aceptar que debe ser una fecha válida, pero hay varios calendarios (por ejemplo, el número de mes puede ser 13, el año puede ser más de 5000).

Answer 8

Validar para un entero y ser útil; Creo que algo más: un sistema abusivo/hermano mayor/motorredre es una mala idea.

Las personas deben poder mentir en estos formularios si lo desean; no es algo legal, es un sitio web.

No lo tome tan en serio.

Answer 9

Creo que la validación es increíblemente importante, pero no necesariamente en su situación. Lo cual no quiere decir que su situación sea trivial, solo tengo mis propias liendres orientadas a la fecha para elegir.

Específicamente, mi preocupación siempre es mantener las cosas en orden lógico. Si alguien dice que nació en 1802, está bien (sorta), solo quiero que su fecha de graduación sea mayor que su fecha de nacimiento. Pero se tropieza con pequeños problemas molestos cuando se trata de tiempo (como en horas y minutos), por ejemplo, si un usuario elige 8:30 como hora de inicio y luego elige 9:15 como hora de finalización, pero luego se da cuenta de que el la hora de finalización fue a las 8:45. Deciden cambiar el 9 por un 8 con la intención de cambiar los minutos a: 45. Pero mi script de validación está demasiado ocupado diciendo "¡Oye, espera! 8:15 es antes de las 8:30, ¡buen intento!" pero no puedo arriesgarme a dejar que lo dejen mal, etc. etc.

Para su situación específica, me inclino por lo que es ético correcto. Porque como se ha señalado, alguien podría estar ingresando un historial familiar (con fechas de nacimiento en el 1600) o futuras compras (con fechas posteriores al día de hoy), por lo que no existe un límite realista en las fechas en general. Pero existen límites para su escenario, por ejemplo:

Si la edad es inferior a la edad legal para trabajar (16 en la mayoría de las partes de los EE. UU.), Ni siquiera ofrezca más que ese año como opción (si está utilizando desplegable).

Si la edad está más allá de la edad razonable de trabajo (que puede ser un tema delicado) ofrezca el valor más alto en función de la edad de jubilación y simplemente agregue un ">" antes de ese año. Si alguien tiene 75 años y solicita un trabajo a nivel de administrador, estarán más contentos de que haya simplificado las cosas en lugar de haber ofendido que no haya enumerado su año de nacimiento. En todo caso, quedarán impresionados (creo) que siguieron esta ruta en lugar de nada en absoluto, lo que implica que no deberían perder el tiempo.

Al final tienes una simple gota abajo muy fácil de guión (ejemplo en PHP):

$currentYear = date('Y'); 

    echo "<select name=\"YearOfBirth\">"; 

for($i = 16; $i <= 64; $i++) { 
    $optionYear = $currentYear - $i; 
    echo "<option value=\"$optionYear\">$optionYear</option>"; 
    } 

    $greaterYear = $currentYear - 65; 
    echo "<option value=\"&gt;$greaterYear\">&gt;$greaterYear</option>"; 

    echo "</select>"; 

Answer 10

Si usted está haciendo esto para nada profesional - como una solicitud de empleo - No puede ser que utilice " ! " en mensajes a los usuarios. Echa un vistazo a cualquier sitio web bien hecho que desees, no vas a encontrarlo de uso común.

Answer 11

Bueno, yo no soy un programador (Más de un BA) aunque estoy tratando de obtener algunas habilidades de desarrollo, ya que creo que me puede ayudar a ser un mejor BA. He hecho un poco de VBA (No te rías).

De todas formas en el pensamiento sobre esto aquí es mi granito de arena

1) Dejar caer el humor. Lo que es gracioso para ti ahora no será para otra persona. Además, lo divertido después de dos o tres va no es divertido después de los 25 o 30 años, ¡es aburrido incluso si se trata de una multitud de jocosos! 2) Estoy llegando a la idea de que, a menos que pueda validar definitivamente algo que está completamente equivocado, por ejemplo, E.g. no desea permitir que alguien ingrese un valor < 0, entonces debería considerar advertencias en lugar de prevención a través de diálogos o lo que sea que el estándar OS sea.

Hey ¿qué sé yo, En una semana me he cambiado de opinión (yo soy un analista de negocios) y va a exigir repsonses instantáneos de los desarrolladores; ->

Answer 12

Validación frente a la corrección
El punto de validación de entrada es garantizar que todos los elementos estén dentro del rango permitido y esperado por el procesamiento posterior; es decir, si su base de datos garantiza todos los solicitantes en el DB tienen 18 años o más, validar eso. Si su base de datos también acepta niños de la escuela que soliciten pasantías, no lo haga.

Todo lo inusual es solo una advertencia.Sí, un valor de 120 años es una locura, debe advertir al usuario y posiblemente marcar este registro como sospechoso/para su revisión. Sin embargo, no tiene sentido rechazarlo (a menos que tenga una regla comercial que indique que todos los solicitantes son menores de 70).

confianza falsa
imaginar lo que sucede si le dice a un usuario que "a descartar poco probable MPD en la entrada". Ella podría decirle a su compañero de trabajo que la fecha de nacimiento ya está "validada". Él termina con una confianza infundada de que el solicitante tiene 90 años, y si fuera falso lo hubieras rechazado.

Todo el procesamiento posterior, ya sea humano o por computadora, debe seguir suponiendo que la fecha de nacimiento puede ser incorrecta, solo por un error tipográfico. Está tratando de crear una garantía que no puede realmente hacer. Muchos usuarios confían en la computadora que usan cada día más que en un extraño, están tratando de imponer esta confianza, que es la falacia de IMO.

Transmutación
Muchas aplicaciones viven mucho más tiempo que el implementador original, imaginó, y bastante serán utilizados para propósitos más allá de sus sueños más salvajes. Construir en límites artificiales que no simplifican el procesamiento real ni el trabajo del operador no ayudan realmente.

(Eso me pone probablemente en la categoría de no-absurdo de su cliente - pero thst es mi manera de ser "anal acerca de la validación": saber cuándo parar :))

Answer 13

Vamos a usar años de dos dígitos en todos lados. ¡Nadie va a usar nuestro software después de 1999!

Answer 14

Al preguntar a las personas vivas por su fecha de nacimiento, solo rechacen los valores que definitivamente son incorrectos. Cualquier fecha de nacimiento en el futuro es definitivamente incorrecta. Y dibujaría una línea y diría que cualquier fecha de nacimiento anterior (digamos) 1880 es definitivamente incorrecta. Cualquier otra cosa es una fecha de nacimiento válida.

Por lo tanto, cualquier fecha de nacimiento que no supere las pruebas anteriores se rechazará con un mensaje en el campo, como "Esta fecha está en el futuro/demasiado en el pasado. Ingrese su fecha de nacimiento".

Cualquier otra fecha de nacimiento es válida (tal vez el usuario realmente tiene 11 años o 108). Pero la forma general puede ser rechazada por las reglas comerciales. Por ejemplo, "debe tener al menos 18 años para presentar la solicitud".

La idea es validación de campo individual por separado de la validación de formulario. Confundirlos produce reglas complicadas. Separar significa que puede volver a utilizar las reglas para el campo (por ejemplo, "Fecha de nacimiento de una persona viva debe estar entre 1/1/1880 y hoy") en otros contextos.

Answer 15

Simplemente deje que el usuario elija una fecha. El usuario debe tener el control ... no el sistema/desarrollador. La única fecha que debe evitar con respecto a DOB es el futuro ya que es incorrecto (es decir, evitar errores de diseño). El selector de fecha que proporcione debe manejar cualquier problema de formato de fecha.

Y definitivamente no arrojes ninguna descarada excepciones/mensajes. Su mensaje debería ayudar al usuario a reconocer & al recuperarse de un error.

Espero que ayude.

Answer 16

Creo que debe considerar sus requisitos reales al diseñar validaciones. Sí, si el campo es un campo de fecha (y quizás más importante si almacena una fecha, pero un dba menos que estelar lo convirtió en varchar), asegúrese de enviar solo una fecha válida. Esto es crítico. Las fechas no válidas causan todo tipo de problemas al consultar los datos.Si se trata de una fecha que necesariamente debe haberse producido en el pasado, limite el intervalo de fechas a la fecha actual o anterior.

Después de eso ve con lo que tu cliente quiere. Si quieren pagar por ti para eliminar a las personas menores de edad laboral, te lo dirán. No aceptar un límite superior de edad puede provocarle problemas legales por discriminación por edad. El cliente puede no querer que hagas esto tampoco.

Answer 17

A continuación se presentan los cheques que se pueden hacer al validar la fecha de nacimiento:

calcular la edad de la fecha de nacimiento y haz las siguientes comprobaciones

EDAD> XX [XX es la edad min requerido para aplicar]

eDAD < XX {debería lanzar un mensaje de mencionar que usted no es lo suficientemente mayor}

eDAD = XX

Si no hay un límite superior de edad, entonces podemos tomar como la edad de jubilación otra cosa verificar con el límite superior para los próximos dos cheques

EDAD < edad de jubilación

EDAD> Jubilación Edad {debe lanzar un mensaje mentiong que son demasiado viejo para aplicar}

EDAD = jubilación Edad

DOB es una fecha válida (dando fecha válida)

DOB no es válido -

Enter 0 in either of day/month/Year 

Enter some negative Value 

Enter some invalid date e.g. 30th feb or 32 Jan etc 

Enter valid date with different separators (although the date is a valid one but due to different separators it will become an invalid one) 

Introduzca la fecha con diferentes formatos como dando dd/mm/aaaa, dd/mm/aa, dd/MON/aaaa etc.

Ingrese una fecha futura (no válida aquí como su propósito es algo diferente)