Esta respuesta no tiene mucho intento de dar una respuesta completa, sino más bien una explicación de lo que es (probablemente) que pasa y por qué algunas de las otras respuestas son buenas soluciones.
La explicación rápida es que esto parece ser una lógica pobre/decisión de diseño para la inmediata ejecución de la integridad de los datos reglas a expensas de los recursos naturales, la entrada de datos fácil. En resumen, si usted necesita para cambiar la "a" de tiempo de AM a PM (o viceversa), es probable que usted necesita para hacer el cambio de AM/PM en primer lugar, a continuación, cambiar la hora y minuto (lo que podría explicar fácilmente por qué sólo puede ver que alrededor del 50% del tiempo).
Solución Roundup
Como bmike sugiere, mediante Cmd+N para una rápida entrada al evento es quizás la solución más fácil, o al menos el más consistentemente más fácil. (Que ni siquiera tienen que pensar si vas a tener que cambiar de AM/PM).
Felix_Sim la solución de utilizar las teclas de flecha para cambiar la hora, también se trabaja, ya que cambia automáticamente AM/PM como los cambios de hora de 11 a 12. Esto debería funcionar bien, a pesar de que fácilmente podría ser menos eficiente con numerosos eventos con duración de varias horas.
Si no te importa cambiar a Tiempo de 24 Horas (Preferencias del Sistema > Idioma y Región), entonces mwd27 de la solución de trabajo, porque no hay ninguna AM/PM interruptor para ponerse en el camino.
Por último, también puede asegurarse de que el cambio de AM/PM en primer lugar, a continuación, volver a la hora. No es elegante, pero funciona.
Me gustaría también recomendamos el envío de información a Apple solicitando tiempo no será validado hasta que después de haber sido completamente introducido, en lugar de mientras está siendo activamente entró.
Explicación, Observaciones E Historia
El problema parece ocurrir en Mountain Lion y Mavericks bajo estas condiciones:
- La introduce automáticamente "a" y "desde" los tiempos son tanto "AM" o ambos "PM", y
- El usuario intenta cambiar la "a" de tiempo a un momento en que se requieren:
- la alternancia de AM/PM, y
- la nueva hora en un número inferior al de la hora en el campo "de" tiempo, y
- la hora se introduce antes de que AM/PM está cambiado.
El problema parece ser el resultado de cómo Calendario asegura que la "a" de tiempo es más tarde que el "de" tiempo (para evitar una duración negativo).
En Lion y versiones anteriores, el Calendario (o iCal, en ese momento) comprobar que la "a" de tiempo fue más tarde que "a partir de" después de que el usuario termine de ingresar todos los valores de fecha y hora de campos (en realidad era un solo campo con varias partes en esa versión, en lugar de separar los campos). Si en un momento anterior se ha introducido, volverá a la anterior de tiempo válido. En Mountain Lion y Mavericks, el Calendario hace esta comprobación como cada campo individual se inscribe, lo que es imposible cambiar la hora en la "a" a un pequeño número de "de" hasta que AM/PM está cambiado.
Ejemplo: Digamos que usted tiene un evento, "a partir de las 9:00 AM a 10:00 AM" y desea cambiarlo a "a partir de las 9:00 AM a 3:00 PM". La forma esperada para entrar en el "a" el tiempo es entrar en "3" de la hora, a continuación, cambiar "AM" a "PM". He aquí lo que sucede:
-
Lion: El usuario puede escribir "3" en la "a" hora, a continuación, cambiar "AM" a "PM", a continuación, salga de la fecha y hora campo.
-
ML & Mavericks: El usuario puede escribir "3" en la "a" a la hora, pero, debido a que "SOY" ha"t ha cambiado todavía, con la consiguiente "a" de tiempo sería de 3:00 de la mañana, que no es válida, ya que"s antes de las 9:00 AM, por lo que se redondea a la unidad más cercana posible de tiempo de validez (en lugar de volver a la última válida del tiempo que fue introducido), que es de 9:00 AM.
