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
어느 것이 맞습니까? 아니면 최고? 이것에 대한 표준이 있습니까?
답변
JSON 자체 는 날짜를 표현하는 방법을 지정하지 않지만 JavaScript는 표현 방법을 지정합니다.
당신은 해야한다 에 의해 방출되는 형식을 사용 Date의 toJSON방법 :
2012-04-23T18:25:43.511Z
이유는 다음과 같습니다.
-
인간이 읽을 수 있지만 간결합니다.
-
올바르게 정렬
-
시간을 다시 설정하는 데 도움이되는 소수 초가 포함됩니다.
-
ISO 8601에 따릅니다
-
ISO 8601은 10 년 이상 국제적으로 잘 확립되어 있습니다.
즉 , 지금까지 쓰여진 모든 날짜 라이브러리는 “1970 년 이후의 밀리 초”를 이해할 수 있습니다. 따라서 손쉬운 이식성을 위해 ThiefMaster 가 옳습니다.
답변
JSON은 날짜에 대해 아무것도 모릅니다. .NET의 기능은 비표준 핵 / 확장입니다.
DateJavaScript 로 객체 로 쉽게 변환 할 수있는 형식 , 즉 전달할 수있는 형식을 사용합니다 new Date(...). 가장 쉽고 아마도 가장 휴대 가능한 형식은 1970 년 이후 밀리 초가 포함 된 타임 스탬프입니다.
답변
올바른 형식은 없습니다 . JSON 사양은 그것을 할 너무 많은 다른 방법이 왜 날짜를 교환하는 형식을 지정하지 않습니다.
최상의 형식은 아마도 ISO 8601 형식으로 표현 된 날짜 일 것 입니다 ( Wikipedia 참조 ). 잘 알려져 있고 널리 사용되는 형식이며 다양한 언어로 처리 할 수있어 상호 운용성에 매우 적합합니다. 예를 들어, 생성 된 json을 제어 할 수있는 경우 데이터를 json 형식으로 다른 시스템에 제공하는 경우 날짜 교환 형식으로 8601을 선택하는 것이 좋습니다.
예를 들어, 생성 된 json을 제어 할 수없는 경우 여러 기존 시스템의 json 소비자 인 경우이를 처리하는 가장 좋은 방법은 날짜 분석 유틸리티 기능을 사용하여 예상되는 다른 형식을 처리하는 것입니다.
답변
에서 RFC 7493합니다 (I-JSON 메시지 형식) :
I-JSON은 요청한 사람에 따라 Internet JSON 또는 Interoperable JSON을 나타냅니다.
프로토콜에는 종종 타임 스탬프 또는 지속 시간을 포함하도록 설계된 데이터 항목이 포함됩니다. RFC 3339에 지정된대로 이러한 모든 데이터 항목을 ISO 8601 형식의 문자열 값으로 표현하고 소문자 대신 대문자를 사용하고 시간대를 기본값으로 포함하지 않으며 선택적 후행 초를 추가로 제한하는 것이 좋습니다. 값이 “00”인 경우에도 포함됩니다. 또한 지속 시간을 포함하는 모든 데이터 항목은 RFC 3339 부록 A의 “지속 기간”생산과 동일한 추가 제한 사항을 준수하는 것이 좋습니다.
답변
참고 로이 형식이 사용되는 것을 보았습니다.
Date.UTC(2017,2,22)함수에서 지원하는 JSONP 와 함께 작동 $.getJSON()합니다. 사람들이 이런 식으로 일을하고 있기 때문에이 접근법을 추천 할 정도로 확실하지 않습니다.
FWIW : 통신 프로토콜에서 epoch 이후 초를 사용하지 말고 epoch 이후 밀리 초를 사용하지 마십시오. 무작위로 윤초가 구현되어 위험에 처하게됩니다.
반려 동물은 싫어하지만 많은 사람들은 UTC가 GMT의 새로운 이름 일 뿐이라고 생각합니다. 시스템이 윤초를 구현하지 않으면 GMT를 사용하는 것입니다 (잘못된 경우에도 종종 UTC라고 함). 윤초를 완전히 구현하면 실제로 UTC를 사용하고 있습니다. 미래의 윤초는 알 수 없습니다. 필요에 따라 IERS에 의해 게시되며 지속적인 업데이트가 필요합니다. 윤초를 구현하려고 시도하지만 구식 참조 테이블이 포함되어 있고 구식이 아닌 참조 테이블을 생각하는 시스템을 실행하는 경우 (GMT 또는 UTC가 아님) UTC가 아닌 이상한 시스템이 있습니다.
이 날짜 카운터는 세분화 된 형식 (y, m, d 등)으로 표현 된 경우에만 호환됩니다. 그들은 절대 형식으로 호환되지 않습니다. 명심하십시오.
답변
의심스러운 경우 F12 (Firefox의 경우 Ctrl + K)를 눌러 최신 브라우저의 자바 스크립트 웹 콘솔로 이동하여 다음을 작성하십시오.
new Date().toISOString()출력합니다 :
“2019-07-04T13 : 33 : 03.969Z”
타다 !!
답변
범용 상호 운용성을 위한 최상의 형식 은 ISO-8601 문자열이 아니라 EJSON에서 사용하는 형식이라고 생각합니다.
{ "myDateField": { "$date" : <ms-since-epoch> } }
여기에 설명 된대로 : https://docs.meteor.com/api/ejson.html
혜택
- 구문 분석 성능 : 날짜를 ISO-8601 문자열로 저장하는 경우 해당 필드에서 날짜 값을 예상하는 경우 유용하지만 컨텍스트없이 값 유형을 결정해야하는 시스템이있는 경우 모든 문자열을 구문 분석합니다. 날짜 형식.
- 날짜 확인 필요 없음 : 날짜 확인 및 확인에 대해 걱정할 필요가 없습니다. 문자열이 ISO-8601 형식과 일치하더라도 실제 날짜가 아닐 수 있습니다. 이것은 EJSON 날짜로는 절대 일어날 수 없습니다.
- 명확한 유형 선언 : 일반적인 데이터 시스템의 경우 ISO 문자열 을 한 경우에 문자열 로 저장 하고 실제 시스템 날짜 를 다른 경우에는 실제 시스템 날짜 를 ISO-8601 문자열 형식을 채택하려는 경우 기계적으로 허용하지 않습니다. (이스케이프 트릭이나 유사한 끔찍한 해결책없이).
결론
나는 사람이 읽을 수있는 형식 (ISO-8601 문자열)이 80 %의 사용 사례에 유용하고 더 편리 하다는 것을 이해합니다. 실제로 응용 프로그램이 있다면 날짜를 ISO-8601 문자열로 저장 하지 말라고 지시 해서는 안됩니다 이해 하지만 , 특정 값을 확실히 보장해야하는 보편적으로 허용되는 전송 형식의 경우 어떻게 모호성을 허용하고 그렇게 많은 검증이 필요한가?
