Esiste un formato data universale che chiunque al mondo può capire?

10

In Canada, tutti hanno familiarità con il formato della data YYYY-MM-DD. In Europa o in Sudafrica, preferiscono DD-MM-YYYY. Ci sono utenti dal Sud Africa che si confondono con il YYYY-MM-DDformato della data. C'è un modo per gestire questa situazione?

Stavo pensando di utilizzare il seguente formato di metodo per tutti: Feb 02, 2011

— Thierry Lam
fonte

21

Penso che anche il formato AAAA-MM-GG sia uno standard ISO.

— FrustratedWithFormsDesigner,

2

"In Europa o in Sudafrica, preferiscono DD-MM-YYYY." Tranne ad esempio in Ungheria ( YYYY.MM.DD) o in Finlandia ( DD.MM.YYYY), oppure ... Siamo spiacenti, la realtà è disordinata :-(

— Péter Török

6

Che dire di diversi calendari?

4

Quando si raccolgono dati radar (in Nord America), abbiamo usato questo per i nomi di file: prefix_1999_12_23_16_45_53.ext. Motivo principale: questo è stato assolutamente facile da ordinare, RICERCA e analisi. Durante la ricerca, vuoi davvero iniziare prima con l'unità più significativa per raggiungere l'obiettivo al più presto. Questo tipo di stringa è persino compatibile con l'albero binario. Il laboratorio era dominato da studenti europei, ma penso che questo fosse solo buon senso, se non uno standard scientifico. Tuttavia, in un paese in cui sono cresciuto, useremmo GG-MM-AAAA per l'uso quotidiano. Ragionamento: quando ti svegli, qual è la prima parte che vuoi sapere?

— Lavoro

2

@Frustrato, suppongo che il suo punto sia che ci sono calendari con un anno di inizio diverso (come interpreterebbe un musulmano, ad esempio il 30.12.1268?), O mesi lunari (di cui ce ne sono circa 13 all'anno) ecc. Quindi, per essere davvero universal è molto più che concordare su quale numero è il giorno e quale è il mese ...

— Péter Török

15

La parte ambigua è quella di differenziare il giorno dal mese se sono rappresentati da numeri.

02/03 significa 03 febbraio o 02 marzo?

Modificando l'identificatore del mese dal suo numero con il suo nome rimuovi quell'ambiguità. Per rispondere alla tua domanda, la tua variante di Feb 02, 2011sembra essere una buona soluzione.

C'è ancora un potenziale problema con il numero dell'anno se lo scrivi solo con 2 cifre, ma è facile da risolvere (usa 4).

10

E poi puoi semplicemente avere un file di traduzione per i nomi dei mesi in diverse lingue.

— FrustratedWithFormsDesigner,

1

@FrustratedWithFormsDesigner E non dimenticare di ottenere una traduzione professionale anche per le abbreviazioni corrette (ben note).

— Nicole,

Che dire delle lingue che non si preoccupano di nominare i mesi?

— SOLO IL MIO OPINIONE corretta,

19

No. Non esiste un formato data riconosciuto universalmente.

ISO 8601 Definisce uno standard internazionale per i formati di data. Come 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 paesi diversi. Potresti scoprire che esiste una libreria standard per raggiungere questo obiettivo se il tuo linguaggio di programmazione scelto ha un seguito significativo.

— Kramii
fonte

2

Questo è fantastico Di solito uso YYYYMMDD per file di registro, ecc. Ora posso dire di essere solo conforme ISO-8601!

— Mark Harrison,

1

Quando uso ISO 8601 di solito trovo che sia meglio formattare esplicitamente l'intera cosa, ovvero 1999-12-25T00: 00: 00.000Z . Sì, sembra sbalorditivo per la persona media ma non c'è possibilità di ambiguità.

— MattDavey,

2

"L'unica soluzione corretta è quella di presentare un formato diverso per diversi paesi." - e come, esattamente, dovrei stampare una data su un documento di trasporto che potrebbe essere spedito in qualsiasi parte del mondo?

— Scott Whitlock,

@ScottWhitlock: Purtroppo, non esiste una soluzione universalmente accettata a questo problema. Se non sai dove viene inviato un pacco quando stampi la data, allora ISO 8601 potrebbe essere la soluzione migliore.

— Kramii,

"L'unica soluzione corretta è quella di presentare un formato diverso per diversi paesi." Direi che non è corretto. Proprio oggi accade che alcune biblioteche mi abbiano aiutato a capire il mio formato di data preferito, basato sulla mia lingua preferita, e provocando confusione. Ma come primo passo poiché non possiamo correggere tutte le culture in questo momento, utilizzare ISO 8601 o testo per mesi o qualcosa del genere.

— Erik I

9

Per questo dovresti usare le informazioni sulla cultura. O almeno il formato di visualizzazione locale.

In JavaScript, è possibile 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.

— Tyanna
fonte

5

Andrei con AAAA-MM-GG (e scrivo sempre anni a quattro cifre e mesi e giorni a due cifre). YYYY-DD-MM, per quanto ne sappia, è raro o raro, quindi il formato YYYY-MM-DD è quello con la minima ambiguità, e alla fine i tuoi utenti prenderanno piede. Inoltre, ottieni il vantaggio di un ordinamento banale.

— jprete
fonte

2

Puoi dare a ogni utente il proprio locale, che quindi rende le date e altre informazioni in base alle loro preferenze locali?

1

Molte volte è possibile configurare le impostazioni internazionali e l'utilizzo di I18n nella maggior parte dei framework.

— chiurox
fonte

0

In generale, dovrai specificare sia il formato che il valore. Questo è l'unico modo per evitare qualsiasi confusione. Ad esempio, puoi dire "2011-02-02 (AAAA-MM-GG)". Viene a scapito della semplicità e della leggibilità, quindi conosci il tuo pubblico.

Ovviamente puoi dire "D'ora in poi, tutte le date sono nel formato AAAA-MM-GG ...." Quindi "02-02-2011" che apparirà in seguito sarà chiaro. Può essere più appetibile, ma ancora una volta, conosci il tuo pubblico.

— yfeldblum
fonte

Esatto, tranne che nel giorno estone = päev e nel mese = kuu, in Filippino sono: araw e buwan, in finlandese: päivä, kuukausi, in ungherese: nap, hónap, in indonesiano: hari, bulan, in malteese: jum, xahar , in rumeno: zi, lună, in turco: gün, ay, in vietnamita: ngày, tháng ... per non parlare di molte lingue in cui entrambi i mesi non iniziano con m o il giorno non inizia con d (tedesco: Monat, Tag ) nonché lingue che non usano nulla di simile all'alfabeto latino.

— Lavoro

1

Bene, "2011-02-02" è inequivocabile in ogni caso ...;)

— Martin

0

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 immagino che la prima interpretazione sia più naturale.

— ggambett
fonte

1

Numeri romani? "Naturale?"

— Wonko the Sane,

@Wonko, "naturale", nel senso che in quel contesto XI ha maggiori probabilità di essere interpretato come un mese che come un giorno. Ammetto che è estremamente soggettivo.

— ggambett,

+1, stavo pensando qualcosa del genere da solo. tuttavia, sono anche d'accordo con i tuoi critici.

— Lavoro

Non avendo mai visto quel formato, avrei prima pensato "errore di battitura" o "errore di traduzione" prima che mi venisse in mente "numeri romani". Solo allora avrei cercato di indovinare il significato.

— Wonko the Sane,

Per non parlare del fatto che il 3 / II / 2011 finirà per essere interpretato come novembre.

— MSalters

0

Direi che dipende da cosa stai facendo, da quanto controllo hai sull'input e lo stai memorizzando da qualche parte?

Per l'archiviazione, vorrei utilizzare ciò che è stato suggerito da Mike Dunlavey:

AAAAMMGGHHMMSS dove l'ora è in UTC è il modo in cui vado ogni volta che ho una scelta, per i motivi che mi dai. Quando non ho scelta, lascio che l'utente scelga.

Non ha lasciato questo come risposta, quindi lo farò.

Ancora una cosa: guarda la seguente schermata di come inserire la data di scadenza CC: http://www.ubercart.org/files/credit_card_checkout.jpg

La cosa grandiosa 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, includere sia il numero che il nome localizzato. Per anno e giorno utilizzare le caselle numeriche Su / Giù o combinate. Quindi, anche il controllo del calendario sembra intelligente.

Come ho detto, dipende. Per l'archiviazione: se si utilizza un database, verificare se fornisce già un buon formato di dati non ambiguo. Se si utilizza un altro metodo, vedere se "AAAAMMGGHHMMSS dove l'ora è in UTC" aiuta. Per presentarlo all'utente, prendi in considerazione quali paesi / locali possono essere eventualmente coinvolti, quindi scegli il tipo di rappresentazione "Non farmi pensare" più diretto. Considera anche di fornire un'opzione.

Infine, controlla alcuni prodotti interessanti che già fanno qualcosa di simile e prova a scoprire come lo fanno.

— Lavoro
fonte

ah merda, quando ho letto lo screenshot pensavo che stessimo parlando dell'11 novembre ... solo per renderci conto che il giorno non era necessario quando si parla della data di scadenza della carta di credito: /

— Matthieu M.

@Matthieu M., sì, è un po 'fuorviante :) Tuttavia, se hai in mano un CC e stai per eseguire l'immissione dei dati, allora forse aiuta più di quanto faccia male. Se ci fossero tre scatole - una per il giorno, allora questo potrebbe essere meno ambiguo.

— Giobbe

0

Non esiste un formato universale di data e ora per gli utenti finali del sito web. Inoltre, non esiste un singolo valore data / ora perché il valore è diverso per fuso orario del cliente. Dovresti usare la globalizzazione - il suo targeting di dati, ora, valuta, calendario, formati nubmer basati sulla cultura degli utenti (può essere ricevuto dalle lingue accettate passate dal browser dell'utente o tramite switch implementato direttamente nella tua applicazione). Alcune API (ad esempio .NET) hanno il supporto diretto di queste funzionalità.

Per memorizzare la data e l'ora nel database utilizzare il formato universale - UTC (coordinare l'ora universale).

— Ladislav Mrnka
fonte

UTC non è così universale: se vuoi prendere in considerazione i secondi bisestili, dovresti usare TAI

— mouviciel,

-2

È un peccato che tutta l'intelligenza nel mondo informatico internazionale non possa rompere questo dado.

Non Microsoft né altri fornitori hanno preso in considerazione l'aggiunta di una maschera di data che farebbe apparire il mese pieno di zero, proprio come il giorno, ma come tre cifre. L'adozione della pratica contribuirebbe a promuovere una nuova serie di formati di data modificati che sono matematicamente equivalenti pur rimanendo facili da identificare e distinguere in uno dei tradizionali layout di data. Questo è:

0MM-GG-AAAA, ad es. 002-03-2016 per febbraio 03,2016
GG-0MM-AAAA, ad es. 03-002-2016 per il 03-feb-2016
AAAA-0MM-GG, ad es. 2016-002-03 per il 2016-02-03
AAAA-GG-0MM, ad esempio 2016-03-002 (se qualcuno voleva usarlo!)

Sembra troppo facile risolverlo in questo modo ... Immagino che semplicemente non venda bene.

— FBTHFL
fonte

2

Tutto quello che posso dire è: xkcd.com/927 Abbiamo già uno standard ISO per le date e non ne abbiamo bisogno.

— Simon B,