Questa risposta non cerca tanto di fornire una risposta completa, ma piuttosto una spiegazione di cosa sta succedendo (probabilmente) e perché alcune delle risposte degli altri sono buone soluzioni.
La rapida spiegazione è che questa sembra essere una scarsa scelta logica / progettuale per l'applicazione immediata delle regole di integrità dei dati a scapito della naturale e facile immissione dei dati. In breve, se è necessario modificare il tempo "da" a quello da AM a PM (o viceversa), è probabile che sia necessario apportare prima la modifica a AM / PM, quindi quindi modificare l'ora e l'ora; minuto (che potrebbe facilmente spiegare perché lo si può vedere solo circa il 50% delle volte).
Roundup soluzione alternativa
-
Come suggerisce bmike, l'uso di Cmd + N per l'immissione rapida di un evento è forse la soluzione più semplice, o almeno la più semplice. (Non devi nemmeno pensare se dovrai cambiare AM / PM).
-
Anche la soluzione di Felix_Sim di usare i tasti freccia per cambiare l'ora funziona, perché cambierà automaticamente AM / PM mentre l'ora cambia da 11 a 12. Ciò dovrebbe funzionare bene, anche se potrebbe facilmente essere meno efficiente con numerosi eventi con durata di diverse ore.
-
Se non ti dispiace passare a 24 ore (Preferenze di Sistema > Lingua e Regione), allora la soluzione di mwd27 funzionerà, perché non ci sono switch AM / PM da intralciare.
-
Infine, potresti anche assicurarti di modificare prima AM / PM, quindi tornare indietro all'ora. Non è elegante, ma funzionerà.
Inoltre, ti consigliamo vivamente di inviare un feedback ad Apple in modo che il tempo di richiesta non venga convalidato fino a dopo è stato inserito completamente, piuttosto che mentre viene inserito attivamente.
Spiegazione, osservazioni e amp; Storia
Il problema sembra verificarsi in Mountain Lion e Mavericks in queste condizioni:
- I tempi di "a" e "di" inseriti automaticamente sono sia "AM" sia "PM" e
- L'utente tenta di cambiare il tempo "a" in un tempo che richiederà:
- attiva / disattiva AM / PM, e
- la nuova ora è un numero inferiore all'ora nel tempo "da", e
- l'ora è inserita prima AM / PM è cambiata.
Il problema sembra essere il risultato di come Calendar assicura che l'ora "a" sia successiva all'ora "da" (per evitare una durata negativa).
In Lion e in precedenza, Calendar (o iCal, in quel momento) controllava che il tempo "to" era successivo a "from" dopo che l'utente ha terminato di inserire all date & campi temporali (in realtà era un singolo campo con più parti in quella versione, piuttosto che campi separati). Se è stata immessa un'ora precedente, verrà ripristinata la precedente ora valida. In Mountain Lion e Mavericks, Calendar rende questo controllo as ogni singolo campo viene inserito, rendendo impossibile cambiare l'ora in "a" a un numero inferiore a "from" fino a quando AM / PM non viene modificato .
Esempio: Dì che hai un evento, "dalle 9:00 alle 10:00 AM" e vuoi cambiarlo in "dalle 9:00 alle 3:00 PM". Il modo previsto per inserire il tempo "to" è inserire "3" per l'ora, quindi cambiare "AM" in "PM". Ecco cosa succede:
-
Lion: l'utente può digitare "3" nell'ora "to", quindi cambiare "AM" in "PM", quindi uscire dalla data & campo temporale.
-
ML & Mavericks: l'utente può digitare "3" nell'ora "a", ma, poiché "AM" non è ancora stato modificato, il tempo "a" risultante sarà 3:00 AM, che non è valido perché questo è prima delle 9:00, quindi è arrotondato al più vicino possibile tempo valido (piuttosto che tornare all'ultimo tempo valido che è stato inserito), che è 9:00.