Essa resposta não tenta fornecer uma resposta completa, mas uma explicação do que (provavelmente) está acontecendo e por que algumas das respostas de outras pessoas são boas soluções.
A explicação rápida é que parece uma péssima decisão de lógica / design para imposição instantânea de regras de integridade de dados à custa de entrada fácil e natural de dados. Em resumo, se você precisar alterar o horário "para" de AM para PM (ou vice-versa), provavelmente precisará fazer a alteração para AM / PM primeiro e depois alterar a hora e os minutos (o que poderia explicar facilmente por que você pode ver apenas cerca de 50% das vezes).
Resumo da solução alternativa
Como bmike sugere, usar Cmd+ Npara entrada rápida de eventos talvez seja a solução mais fácil, ou pelo menos a mais consistente. (Você nem precisa pensar se precisará alterar AM / PM).
A solução de Felix_Sim de usar as teclas de seta para alterar a hora também funciona, porque isso mudará automaticamente AM / PM à medida que a hora muda de 11 para 12. Isso deve funcionar bem, embora possa facilmente ser menos eficiente com vários eventos com durações de várias horas .
Se você não se importa de mudar para o Horário de 24 horas (Preferências do Sistema> Idioma e Região), a solução do mwd27 funcionará, porque não há uma opção AM / PM para atrapalhar.
Por fim, você também pode mudar a AM / PM primeiro e depois voltar para a hora. Não é elegante, mas vai funcionar.
Também recomendo fortemente enviar um feedback à Apple solicitando que o tempo não seja validado até depois de ter sido completamente inserido, e não enquanto estiver sendo inserido ativamente.
Explicação, Observações e História
O problema parece ocorrer no Mountain Lion e Mavericks sob estas condições:
- Os horários "a" e "de" inseridos automaticamente são "AM" ou "PM" e
- O usuário tenta alterar o horário "para" para um horário que exigirá:
- alternar AM / PM e
- a nova hora é um número menor que a hora no horário "de" e
- a hora é inserida antes da alteração de AM / PM.
O problema parece ser o resultado de como o Calendário garante que o tempo "até" seja posterior ao tempo "de" (para evitar uma duração negativa).
No Lion e versões anteriores, o Calendar (ou iCal, naquele momento) verificava se o horário "para" era posterior a "de" depois que o usuário terminava de inserir todos os campos de data e hora (na verdade, era um único campo com várias partes nesse versão, em vez de campos separados). Se um horário anterior fosse inserido, ele retornaria ao horário válido anterior. No Mountain Lion e Mavericks, o Calendar faz essa verificação à medida que cada campo individual está sendo inserido, tornando impossível alterar a hora em "para" para um número menor que "de" até que o AM / PM seja alterado.
Exemplo: digamos que você tenha um evento "das 9:00 às 10:00" e deseje alterá-lo para "das 9:00 às 15:00". A maneira esperada de inserir a hora "para" é digitar "3" durante a hora e depois alterar "AM" para "PM". Aqui está o que acontece:
- Leão: o usuário pode digitar "3" na hora "até" e depois alterar "AM" para "PM" e sair do campo de data e hora.
- ML e Mavericks: o usuário pode digitar "3" na hora "para", mas, como "AM" ainda não foi alterado, o tempo "para" resultante seria 3:00, o que não é válido porque "s antes das 9:00, portanto, é arredondado para o horário válido mais próximo possível (em vez de reverter para o último horário válido inserido), que é 9:00.