„Właściwy” format daty JSON

Widziałem tak wiele różnych standardów formatu daty JSON:

"\"\\/Date(1335205592410)\\/\""         .NET JavaScriptSerializer
"\"\\/Date(1335205592410-0500)\\/\""    .NET DataContractJsonSerializer
"2012-04-23T18:25:43.511Z"              JavaScript built-in JSON object
"2012-04-21T18:25:43-05:00"             ISO 8601

Który jest właściwy? A może najlepiej? Czy jest w tym jakiś standard?

Sam JSON nie określa sposobu reprezentacji dat, ale JavaScript.

Państwo powinno użyć formatu emitowanego przez Date„s toJSONmetody:

2012-04-23T18:25:43.511Z

Dlatego:

1. Jest czytelny dla człowieka, ale także zwięzły

2. Sortuje się poprawnie

3. Zawiera ułamkowe sekundy, które mogą pomóc przywrócić chronologię

4. Jest zgodny z ISO 8601

5. ISO 8601 jest znana na całym świecie od ponad dekady

6. ISO 8601 jest zatwierdzony przez W3C , RFC3339 i XKCD

To powiedziawszy , każda napisana biblioteka dat może zrozumieć „milisekundy od 1970 roku”. Więc dla łatwego przenoszenia, ThiefMaster ma rację.

JSON nic nie wie o datach. To, co robi .NET, to niestandardowy hack / rozszerzenie.

Użyłbym formatu, który można łatwo przekonwertować na Dateobiekt w JavaScript, tj. Takiego, który można przekazać new Date(...). Najłatwiejszym i prawdopodobnie najbardziej przenośnym formatem jest znacznik czasu zawierający milisekundy od 1970 roku.

Nie ma odpowiedniego formatu ; Specyfikacja JSON nie określa formatu wymiany dat, dlatego jest tak wiele różnych sposobów, aby to zrobić.

Najlepszym formatem jest prawdopodobnie data reprezentowana w formacie ISO 8601 ( patrz Wikipedia ); jest to dobrze znany i szeroko stosowany format, który można obsługiwać w wielu różnych językach, dzięki czemu doskonale nadaje się do współpracy. Jeśli na przykład kontrolujesz wygenerowany plik Json, udostępniasz dane innym systemom w formacie json, wybierając 8601 jako format wymiany daty, dobrym wyborem.

Jeśli na przykład nie masz kontroli nad wygenerowanym plikiem Json, jesteś konsumentem oprogramowania Json z kilku różnych istniejących systemów, najlepszym sposobem na to jest skorzystanie z funkcji narzędzia do analizy dat, która obsługuje różne oczekiwane formaty.

Z RFC 7493 (format wiadomości I-JSON) :

I-JSON oznacza Internet JSON lub Interoperable JSON, w zależności od tego, kogo zapytasz.

Protokoły często zawierają elementy danych zaprojektowane w taki sposób, aby zawierały znaczniki czasu lub czasy trwania. ZALECA się, aby wszystkie takie elementy danych były wyrażone jako wartości łańcuchowe w formacie ISO 8601, jak określono w RFC 3339 , z dodatkowymi ograniczeniami, że należy używać wielkich liter zamiast małych liter, aby strefa czasowa nie była domyślna, oraz że opcjonalne końcowe sekundy być uwzględnione, nawet jeśli ich wartość to „00”. ZALECA się również, aby wszystkie elementy danych zawierające czasy trwania były zgodne z produkcją „czas trwania” w dodatku A do RFC 3339, z tymi samymi dodatkowymi ograniczeniami.

Tylko w celach informacyjnych widziałem używany format:

Date.UTC(2017,2,22)

Działa z JSONP, który jest obsługiwany przez $.getJSON()funkcję. Nie jestem pewien, czy posunę się tak daleko, aby zalecić takie podejście ... po prostu wyrzucenie go jako możliwej możliwości, ponieważ ludzie robią to w ten sposób.

FWIW: Nigdy nie używaj sekund od epoki w protokole komunikacyjnym ani milisekund od epoki, ponieważ są one obarczone niebezpieczeństwem dzięki losowej implementacji sekund przestępnych (nie masz pojęcia, czy nadawca i odbiorca poprawnie implementują sekundy przestępne UTC).

Nienawiść do zwierząt domowych, ale wiele osób uważa, że ​​UTC to tylko nowa nazwa GMT - źle! Jeśli twój system nie implementuje sekund przestępnych, oznacza to, że korzystasz z GMT (często nazywany UTC, mimo że jest nieprawidłowy). Jeśli w pełni wykorzystasz sekundy przestępne, naprawdę używasz UTC. Przyszłe sekundy przestępne nie mogą być znane; są one publikowane przez IERS w razie potrzeby i wymagają ciągłych aktualizacji. Jeśli korzystasz z systemu, który próbuje zaimplementować sekundy przestępne, ale zawiera nieaktualną tabelę referencyjną (bardziej powszechną niż mogłoby się wydawać), to nie masz GMT ani UTC, masz dziwny system udający UTC.

Te liczniki daty są kompatybilne tylko wtedy, gdy są wyrażone w formacie z podziałem (y, m, d itp.). NIGDY nie są kompatybilne w formacie epoki. Miej to w pamięci.

W razie wątpliwości wystarczy przejść do konsoli internetowej javascript nowoczesnej przeglądarki, naciskając klawisz F12 (Ctrl + K w przeglądarce Firefox) i napisz:

new Date().toISOString()

Wyjdzie:

„2019-07-04T13: 33: 03.969Z”

Ta-da !!

Uważam, że najlepszym formatem dla uniwersalnej interoperacyjności nie jest ciąg ISO-8601, ale format używany przez EJSON:

{ "myDateField": { "$date" : <ms-since-epoch> } }

Jak opisano tutaj: https://docs.meteor.com/api/ejson.html

Korzyści

1. Analiza wydajności: Jeśli przechowujesz daty jako ciągi znaków ISO-8601, jest to świetne, jeśli oczekujesz wartości daty w tym konkretnym polu, ale jeśli masz system, który musi określać typy wartości bez kontekstu, analizujesz każdy ciąg znaków dla format daty.
2. Nie ma potrzeby sprawdzania poprawności daty: Nie musisz się martwić o sprawdzanie poprawności i weryfikacji daty. Nawet jeśli łańcuch pasuje do formatu ISO-8601, może nie być prawdziwą datą; tak się nigdy nie stanie z datą EJSON.
3. Jednoznaczna deklaracja typu: jeśli chodzi o ogólne systemy danych, jeśli chcesz przechowywać ciąg ISO jako ciąg w jednym przypadku, a rzeczywista data systemowa w innym, ogólne systemy przyjmujące format ciągu ISO-8601 nie pozwolą na to, mechanicznie (bez sztuczek ucieczki lub podobnych okropnych rozwiązań).

Wniosek

Rozumiem, że format czytelny dla człowieka (ciąg ISO-8601) jest pomocny i wygodniejszy w 80% przypadków użycia, i w rzeczywistości nikt nie powinien być informowany, aby nie przechowywał swoich dat jako ciągów ISO-8601, jeśli takie są ich aplikacje rozumiemy, ale dla powszechnie przyjętego formatu transportu, który powinien gwarantować pewne wartości, na pewno daty, w jaki sposób możemy pozwolić na dwuznaczność i potrzebę tak dużej walidacji?

Sam JSON nie ma formatu daty, nie obchodzi go, jak ktokolwiek przechowuje daty. Ponieważ jednak pytanie to jest oznaczone javascript, zakładam, że chcesz wiedzieć, jak przechowywać daty javascript w JSON. Możesz po prostu podać datę do JSON.stringifymetody, a ona użyje Date.prototype.toJSONdomyślnie, która z kolei używa Date.prototype.toISOString( MDN na Date.toJSON ):

const json = JSON.stringify(new Date());
const parsed = JSON.parse(json); //2015-10-26T07:46:36.611Z
const date = new Date(parsed); // Back to date object

Uznałem również, że użyteczne jest użycie reviverparametru JSON.parse( MDN na JSON.parse ) do automatycznej konwersji ciągów ISO z powrotem na daty javascript za każdym razem, gdy czytam ciągi JSON.

const isoDatePattern = new RegExp(/\d{4}-[01]\d-[0-3]\dT[0-2]\d:[0-5]\d:[0-5]\d\.\d+([+-][0-2]\d:[0-5]\d|Z)/);

const obj = {
 a: 'foo',
 b: new Date(1500000000000) // Fri Jul 14 2017, etc...
}
const json = JSON.stringify(obj);

// Convert back, use reviver function:
const parsed = JSON.parse(json, (key, value) => {
    if (typeof value === 'string' &&  value.match(isoDatePattern)){
        return new Date(value); // isostring, so cast to js date
    }
    return value; // leave any other value as-is
});
console.log(parsed.b); // // Fri Jul 14 2017, etc...

Preferowanym sposobem jest użycie 2018-04-23T18:25:43.511Z...

Poniższy obrazek pokazuje, dlaczego jest to preferowany sposób:

Jak widać, Date ma natywną metodę toJSON, którą returnw tym formacie można łatwo przekonwertować na Datejeszcze raz ...

W Sharepoint 2013, pobieranie danych w JSON nie ma formatu do konwersji daty na format tylko daty, ponieważ w tej dacie powinien być format ISO

yourDate.substring(0,10)

To może ci pomóc

„2014-01-01T23: 28: 56.782Z”

Data jest reprezentowana w standardowym i sortowalnym formacie, który reprezentuje czas UTC (wskazany przez Z). ISO 8601 obsługuje również strefy czasowe, zastępując Z wartością + lub - dla przesunięcia strefy czasowej:

„2014-02-01T09: 28: 56.321-10: 00”

Istnieją inne odmiany kodowania strefy czasowej w specyfikacji ISO 8601, ale format –10: 00 jest jedynym formatem TZ obsługiwanym przez obecne parsery JSON. Ogólnie najlepiej jest używać formatu opartego na UTC (Z), chyba że istnieje konkretna potrzeba ustalenia strefy czasowej, w której data została utworzona (możliwe tylko w przypadku generowania po stronie serwera).

NB: var date = new Date (); console.log (data); // śr. 01.01.2014 13:28:56 GMT- 1000 (hawajski czas standardowy)

var json = JSON.stringify(date);
console.log(json);  // "2014-01-01T23:28:56.782Z"

aby powiedzieć, że jest to preferowany sposób, mimo że JavaScript nie ma standardowego formatu

// JSON encoded date
var json = "\"2014-01-01T23:28:56.782Z\"";

var dateStr = JSON.parse(json);  
console.log(dateStr); // 2014-01-01T23:28:56.782Z

Jeśli używasz Kotlin, to rozwiąże twój problem. (Format MS Json)

val dataString = "/Date(1586583441106)/"
val date = Date(Long.parseLong(dataString.substring(6, dataString.length - 2)))

działa dla mnie z parsowaniem serwera

{
    "ContractID": "203-17-DC0101-00003-10011",
    "Supplier":"Sample Co., Ltd",
    "Value":12345.80,
    "Curency":"USD",
    "StartDate": {
                "__type": "Date",
                "iso": "2017-08-22T06:11:00.000Z"
            }
}

Jest tylko jedna poprawna odpowiedź na to pytanie i większość systemów źle ją rozumie. Liczba milisekund od epoki, czyli 64-bitowa liczba całkowita. Strefa czasowa jest problemem związanym z interfejsem użytkownika i nie ma działalności w warstwie aplikacji lub db. Dlaczego db ma dbałość o strefę czasową, skoro wiesz, że zapisze ją jako 64-bitową liczbę całkowitą, wykonaj obliczenia transformacji.

Usuń niepotrzebne fragmenty i traktuj daty jak liczby aż do interfejsu użytkownika. Za pomocą prostych operatorów arytmetycznych można wykonywać zapytania i logikę.

Poniższy kod działał dla mnie. Ten kod wydrukuje datę w formacie DD-MM-RRRR .

DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);

w przeciwnym razie możesz również użyć:

DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);

Myślę, że to naprawdę zależy od przypadku użycia. W wielu przypadkach korzystniejsze może być użycie odpowiedniego modelu obiektowego (zamiast renderowania daty w ciągu), na przykład:

{
"person" :
      {
 "name" : {
   "first": "Tom",
   "middle": "M",
  ...
}
 "dob" :  {
         "year": 2012,
         "month": 4,
         "day": 23,
         "hour": 18,
         "minute": 25,
         "second": 43,
         "timeZone": "America/New_York"
    }   
   }
}

Wprawdzie jest to bardziej szczegółowe niż RFC 3339, ale:

• jest również czytelny dla człowieka
• implementuje odpowiedni model obiektowy (jak w OOP, o ile pozwala na to JSON)
• obsługuje strefy czasowe (nie tylko przesunięcie UTC w danym dniu i godzinie)
• może obsługiwać mniejsze jednostki, takie jak milisekundy, nanosekundy ... lub po prostu ułamkowe sekundy
• nie wymaga osobnego kroku analizy (aby przeanalizować ciąg daty i godziny), parser JSON zrobi wszystko za Ciebie
• łatwe tworzenie przy użyciu dowolnej ramy czasowej lub implementacji w dowolnym języku
• można łatwo rozszerzyć o obsługę innych skal kalendarza (hebrajski, chiński, islamski ...) i epok (AD, BC, ...)
• jest bezpieczny rok 10000 ;-) (RFC 3339 nie jest)
• obsługuje daty całodniowe i zmienne czasy (JavaScript Date.toJSON()nie)

Nie sądzę, aby poprawne sortowanie (jak zauważył funroll dla RFC 3339) jest funkcją, która jest naprawdę potrzebna podczas szeregowania randki w JSON. Dotyczy to także dat i godzin mających takie same przesunięcie strefy czasowej.