In Canada, tutti conoscono il formato della data YYYY-MM-DD . In Europa o in Sud Africa, preferiscono DD-MM-YYYY . Ci sono utenti dal Sud Africa che si confondono con il formato di data YYYY-MM-DD . C'è un modo per gestire questa situazione?
Stavo pensando di utilizzare il seguente formato di metodo per tutti: Feb 02, 2011
La parte ambigua deve differenziare giorno dopo mese se sono rappresentati da numeri.
02/03 significa febbraio 03 o marzo 02?
Cambiando l'identificatore del mese dal suo numero con il suo nome , rimuovi questa ambiguità. Per rispondere alla tua domanda, la tua variante di Feb 02, 2011 sembra essere una buona soluzione.
C'è ancora un potenziale problema con il numero dell'anno se lo stai scrivendo solo con 2 cifre, ma poi è facile da risolvere (usa 4).
No. Non esiste un formato di data universalmente riconosciuto.
ISO 8601 Definisce uno standard internazionale per i formati di data. In quanto tale, è probabilmente il miglior compromesso. Ma come dici tu, agli utenti non piace sempre questo formato.
L'unica soluzione corretta è presentare un formato diverso per i diversi paesi. Potresti scoprire che esiste una libreria standard per ottenere questo risultato se il tuo linguaggio di programmazione scelto ha un seguito significativo.
Dovresti usare le informazioni sulla cultura per questo. O almeno il formato di visualizzazione locale.
In JavaScript, puoi utilizzare il metodo toLocaleString per la classe Date .
Per C # puoi usare la stringa di formato quando usi ToString .
Una rapida ricerca su Google dovrebbe mostrarti come utilizzare la cultura nella lingua che preferisci.
Vorrei andare con YYYY-MM-DD (e scrivere sempre gli anni a quattro cifre e i mesi e i giorni a due cifre). YYYY-DD-MM, per quanto ne so, non è raro che raro, quindi il formato AAAA-MM-GG è quello con la minima ambiguità, e alla fine i tuoi utenti si prenderanno cura di te. Inoltre, ottieni il vantaggio dell'ordinamento elementare.
Puoi assegnare a ciascun utente le proprie impostazioni internazionali, che quindi restituiscono date e altre informazioni in base alle loro preferenze locali?
Molte volte è possibile configurare le impostazioni internazionali e utilizzare I18n nella maggior parte dei framework.
In generale, dovrai specificare sia il formato che il valore. Questo è l'unico modo per evitare qualsiasi confusione. Ad esempio, puoi pronunciare "2011-02-02 (YYYY-MM-DD)". Tuttavia, a scapito della semplicità e della leggibilità, conosci il tuo pubblico.
Puoi, ovviamente, dire "qui di seguito, tutte le date sono nel formato AAAA-MM-GG ...." Quindi "2011-02-02" che appare in seguito non sarà ambiguo. Questo può essere più appetibile, ma, di nuovo, conosci il tuo pubblico.
Questo suggerimento è probabilmente inutile, ma ho visto mesi scritti come numeri romani. Certo, il 3 / XI / 2011 potrebbe essere l'11 novembre o il 3 marzo, ma suppongo che la prima interpretazione sia più naturale.
Direi che dipende da cosa stai facendo, quanto controllo hai sull'input e lo stai memorizzando da qualche parte?
Per l'archiviazione, vorrei utilizzare ciò che è stato suggerito da Mike Dunlavey:
YYYYMMDDHHMMSS where the hour is in UTC is the way I go whenever I have a choice, for the reasons you give. When I don't have a choice, I let the user choose.
Non l'ha lasciato come risposta, quindi lo farò.
Un'altra cosa: guarda la seguente schermata di come inserire la data di scadenza CC: link
Il bello di questo esempio è che non ti fa pensare. Utilizza sia numeri che nomi per il mese. Vorrei prendere in considerazione l'utilizzo di qualcosa di simile per l'input. Per il mese, includi sia il numero che il nome localizzato. Per anno e giorno utilizzare numeri su / giù o caselle combinate numeriche. Quindi, anche il controllo del calendario sembra carino.
Come ho detto, dipende. Per la memorizzazione: se si utilizza un database, verificare se fornisce già un buon formato di dati non ambigui. Se si utilizza un altro metodo, vedere se "AAAAAAAAAAAAAAAAAAAAAAAAAAA" aiuta. Per presentarlo all'utente - prendi in considerazione quali paesi / località possono essere eventualmente coinvolti, quindi scegli il tipo più diretto di "Non farmi pensare". Considera anche di fornire un'opzione.
Infine, controlla alcuni prodotti interessanti che già fanno qualcosa di simile e prova a scoprire come lo fanno.
Non esiste un formato universale di data e ora per gli utenti del sito web. Non esiste anche un singolo valore di data, poiché il valore è diverso per il fuso orario del cliente. È necessario utilizzare la globalizzazione, ovvero il targeting di dati, tempi, valuta, calendario, formati nubmer basati sulla cultura degli utenti (possono essere ricevuti dalle lingue accettate trasmesse dal browser dell'utente o implementate direttamente nella propria applicazione). Alcune API (ad esempio .NET) hanno il supporto diretto di queste funzionalità.
Per la memorizzazione di data e ora in database utilizzare il formato universale - UTC (coordinare l'ora universale).
È spiacevole che tutta l'intelligenza nel mondo informatico internazionale non possa rompere questo pazzo.
Microsoft e altri fornitori non hanno in programma di aggiungere una maschera di data che faccia apparire il mese pieno di zero, proprio come il giorno, ma con tre cifre. L'adozione di una pratica contribuirebbe a promuovere una nuova serie di formati data modificati che sono matematicamente equivalenti, pur rimanendo facili da identificare e distinguere in uno qualsiasi dei tradizionali layout di data. Cioè:
0MM-DD-YYYY, ad es. 002-03-2016 per Feb 03,2016
DD-0MM-YYYY, ad es. 03-002-2016 per il 03-feb-2016
YYYY-0MM-DD, ad es. 2016-002-03 per 2016-02-03
YYYY-DD-0MM, ad es. 2016-03-002 (se qualcuno volesse usarlo!)
Sembra troppo facile risolverlo in questo modo ... Immagino che semplicemente non venda bene.
Leggi altre domande sui tag date-format standards websites formatting ambiguity
