"올바른" JSON 날짜 형식이란 무엇입니까?

질문자 :Kamyar Nazeri

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

이유는 다음과 같습니다.

1. 사람이 읽을 수 있지만 간결합니다.

2. 올바르게 정렬됩니다.

3. 여기에는 연대기를 다시 설정하는 데 도움이 될 수 있는 분수 초가 포함됩니다.

4. ISO 8601을 준수합니다.

5. ISO 8601은 10년 이상 국제적으로 확립되었습니다.

6. ISO 8601은 W3C , RFC3339 및 XKCD에서 보증합니다.

즉 , 작성된 모든 날짜 라이브러리는 "1970년 이후 밀리초"를 이해할 수 있습니다. 그래서 간편한 휴대를 위해 ThiefMaster 가 맞습니다.

funroll

JSON은 날짜에 대해 아무것도 모릅니다. .NET이 하는 일은 비표준 해킹/확장입니다.

JavaScript에서 Date 객체로 쉽게 변환할 수 있는 형식 new Date(...) 전달할 수 있는 형식을 사용합니다. 가장 쉽고 아마도 가장 이식 가능한 형식은 1970년 이후의 밀리초를 포함하는 타임스탬프입니다.

ThiefMaster

올바른 형식이 없습니다 . JSON 사양 은 날짜 교환을 위한 형식을 지정하지 않기 때문에 다양한 방법이 있습니다.

가장 좋은 형식은 틀림없이 ISO 8601 형식으로 표시되는 날짜입니다( Wikipedia 참조 ). 잘 알려져 있고 널리 사용되는 형식이며 다양한 언어에서 처리할 수 있으므로 상호 운용성에 매우 적합합니다. 예를 들어 생성된 json을 제어할 수 있는 경우 json 형식으로 다른 시스템에 데이터를 제공하는 경우 날짜 교환 형식으로 8601을 선택하는 것이 좋습니다.

예를 들어 생성된 json을 제어할 수 없는 경우 여러 기존 시스템의 json 소비자인 경우 이를 처리하는 가장 좋은 방법은 예상되는 다양한 형식을 처리하는 날짜 구문 분석 유틸리티 기능을 사용하는 것입니다.

Russ Cam

RFC 7493(I-JSON 메시지 형식) :

I-JSON은 묻는 사람에 따라 Internet JSON 또는 Interoperable JSON을 나타냅니다.

프로토콜에는 종종 타임스탬프 또는 기간을 포함하도록 설계된 데이터 항목이 포함됩니다. 이러한 모든 데이터 항목은 RFC 3339 에 지정된 대로 ISO 8601 형식의 문자열 값으로 표현하고 소문자 대신 대문자를 사용하고, 표준 시간대를 기본값으로 포함하지 않으며, 선택적 후행 초를 추가로 제한하는 것이 좋습니다. 값이 "00"인 경우에도 포함됩니다. 또한 기간을 포함하는 모든 데이터 항목은 RFC 3339의 부록 A에 있는 "지속 기간" 생산을 준수하며 동일한 추가 제한 사항이 있는 것이 좋습니다.

Bryan Larsen

참고로 다음 형식이 사용되는 것을 보았습니다.

 Date.UTC(2017,2,22)

$.getJSON() 함수에서 지원하는 JSONP 와 함께 작동합니다. 이 접근 방식을 추천할 만큼 멀리 갈지 확신이 서지 않습니다. 사람들이 이런 방식으로 하고 있기 때문에 가능성을 배제하는 것뿐입니다.

FWIW: 통신 프로토콜에서 epoch 이후 초 또는 epoch 이후 밀리초를 사용하지 마십시오. 윤초의 무작위 구현 덕분에 위험이 내포되어 있기 때문입니다(발신자와 수신자 모두 UTC 윤초를 올바르게 구현하는지 여부를 알 수 없음).

일종의 애완 동물 혐오이지만 많은 사람들은 UTC가 GMT의 새로운 이름일 뿐이라고 생각합니다. 잘못된 것입니다! 시스템이 윤초를 구현하지 않으면 GMT(잘못된 경우에도 종종 UTC라고 함)를 사용하고 있는 것입니다. 윤초를 완전히 구현하면 실제로 UTC를 사용하는 것입니다. 미래의 윤초는 알 수 없습니다. 필요에 따라 IERS에 의해 게시되며 지속적인 업데이트가 필요합니다. 윤초를 구현하려고 시도하지만 오래된 참조 테이블(생각보다 더 일반적임)을 포함하는 시스템을 실행하는 경우 GMT도 UTC도 없는 경우 UTC인 것처럼 가장하는 이상한 시스템이 있는 것입니다.

이러한 날짜 카운터는 세분화된 형식(y, m, d 등)으로 표현될 때만 호환됩니다. Epoch 형식에서는 절대 호환되지 않습니다. 그것을 염두에 두십시오.

Tel

확실하지 않은 경우 F12 ( Firefox의 경우 Ctrl + Shift + K) 를 눌러 최신 브라우저의 자바스크립트 웹 콘솔로 이동하고 다음을 작성합니다.

 new Date().toISOString()

출력합니다:

"2019-07-04T13:33:03.969Z"

타다!!

Shayan Ahmad

JSON 자체에는 날짜 형식이 없으며 다른 사람이 날짜를 저장하는 방법을 신경 쓰지 않습니다. 그러나 이 질문은 javascript로 태그가 지정되어 있으므로 JSON에 javascript 날짜를 저장하는 방법을 알고 싶다고 가정합니다. JSON.stringify 메소드에 날짜를 전달할 수 있으며 기본적으로 Date.prototype.toJSON 을 사용하며, 차례로 Date.prototype.toISOString( Date.prototype.toISOString MDN )을 사용합니다.

 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

또한 JSON 문자열을 읽을 때마다 자동으로 ISO 문자열을 자바스크립트 날짜로 다시 변환하기 위해 reviver 매개변수( JSON.parse MDN )를 사용하는 것이 유용하다는 것을 알았습니다.

 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...

Justus Romijn

선호하는 방법은 2018-04-23T18:25:43.511Z ...

아래 그림은 이것이 선호되는 이유를 보여줍니다.

toJSON return 되고 다시 Date 로 쉽게 변환할 수 있는 기본 메서드 toJSON이 있습니다...

Alireza

범용 상호 운용성을 위한 최상의 형식은 ISO-8601 문자열이 아니라 EJSON에서 사용하는 형식이라고 생각합니다.

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

여기에 설명된 대로: https://docs.meteor.com/api/ejson.html

혜택

1. 구문 분석 성능: 날짜를 ISO-8601 문자열로 저장하는 경우 해당 특정 필드 아래에 날짜 값이 예상되는 경우에 유용하지만 컨텍스트 없이 값 유형을 결정해야 하는 시스템이 있는 경우 모든 문자열을 구문 분석합니다. 날짜 형식.
2. 날짜 확인 필요 없음: 날짜 확인 및 확인에 대해 걱정할 필요가 없습니다. 문자열이 ISO-8601 형식과 일치하더라도 실제 날짜가 아닐 수 있습니다. 이것은 EJSON 날짜에서는 절대로 발생할 수 없습니다.
3. 명확한 유형 선언: 일반 데이터 시스템에 관한 한 ISO 문자열 을 한 경우에는 문자열로 저장하고 실제 시스템 날짜 를 다른 경우에는 저장하려는 경우 ISO-8601 문자열 형식을 채택하는 일반 시스템은 기계적으로 이를 허용하지 않습니다. (탈출 트릭이나 이와 유사한 끔찍한 솔루션 없이).

결론

나는 사람이 읽을 수있는 형식 (ISO-8601 문자열) 도움과 사용 사례의 80 %를 더 편리하고, 실제로 아무도는 지금까지 ISO-8601 문자열로 자신의 날짜를 저장하지 말되어야 것을 이해할 수의 어떤 애플리케이션의 경우 이해 하지만 , 특정 값을 확실한 날짜로 보장해야 하는 보편적으로 허용되는 전송 형식에 대해 어떻게 그렇게 많은 유효성 검사가 필요한 모호성과 필요성을 허용할 수 있습니까?

Ciabaros

Sharepoint 2013에서는 JSON으로 데이터를 가져올 때 날짜가 ISO 형식이어야 하기 때문에 날짜를 날짜 전용 형식으로 변환하는 형식이 없습니다.

 yourDate.substring(0,10)

이것은 당신에게 도움이 될 수 있습니다

raghava arr

"2014-01-01T23:28:56.782Z"

날짜는 UTC 시간(Z로 표시)을 나타내는 정렬 가능한 표준 형식으로 표시됩니다. ISO 8601은 또한 Z를 표준 시간대 오프셋의 + 또는 – 값으로 대체하여 표준 시간대를 지원합니다.

"2014-02-01T09:28:56.321-10:00"

ISO 8601 사양에는 시간대 인코딩의 다른 변형이 있지만 –10:00 형식은 현재 JSON 파서가 지원하는 유일한 TZ 형식입니다. 일반적으로 날짜가 생성된 시간대를 파악해야 하는 특별한 필요가 없는 한 UTC 기반 형식(Z)을 사용하는 것이 가장 좋습니다(서버 측 생성에서만 가능).

주의:

 var date = new Date(); console.log(date); // Wed Jan 01 2014 13:28:56 GMT- 1000 (Hawaiian Standard Time) var json = JSON.stringify(date); console.log(json); // "2014-01-01T23:28:56.782Z"

JavaScript에 표준 형식이 없더라도 이것이 선호되는 방법임을 알려주기 위해

 // 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

Maduekwe Chukwuemeka

그것은 parse Server로 나를 위해 일합니다.

 { "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" } }

Kemal Karadag

이것에 대한 정답은 하나뿐이며 대부분의 시스템은 잘못 알고 있습니다. Epoch 이후의 밀리초 수(64비트 정수라고도 함). 시간대는 UI 문제이며 앱 계층이나 db 계층에는 비즈니스가 없습니다. 64비트 정수로 저장할 것이라는 것을 알 때 db가 시간대가 무엇인지 신경쓰는 이유는 다음 변환 계산을 수행하는 것입니다.

불필요한 비트를 제거하고 날짜를 UI까지 숫자로 취급하십시오. 간단한 산술 연산자를 사용하여 쿼리와 논리를 수행할 수 있습니다.

Chad Wilson

다음 코드가 저에게 효과적이었습니다. 이 코드는 날짜를 DD-MM-YYYY 형식으로 인쇄합니다.

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

그렇지 않으면 다음을 사용할 수도 있습니다.

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

Aniket Kumar Shrivastava

나는 그것이 실제로 사용 사례에 달려 있다고 생각합니다. 많은 경우에 다음과 같이 (날짜를 문자열로 렌더링하는 대신) 적절한 개체 모델을 사용하는 것이 더 유리할 수 있습니다.

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

분명히 이것은 RFC 3339보다 더 장황하지만 다음과 같습니다.

• 사람도 읽을 수 있다
• 적절한 객체 모델을 구현합니다(JSON이 허용하는 한 OOP에서와 같이)
• 시간대를 지원합니다(주어진 날짜와 시간의 UTC 오프셋뿐만 아니라)
• 밀리초, 나노초, ... 또는 단순히 분수 초와 같은 더 작은 단위를 지원할 수 있습니다.
• 날짜-시간 문자열을 구문 분석하기 위해 별도의 구문 분석 단계가 필요하지 않으며 JSON 구문 분석기가 모든 작업을 수행합니다.
• 모든 날짜-시간 프레임워크로 쉽게 생성하거나 모든 언어로 구현
• 다른 달력 척도(히브리어, 중국어, 이슬람 ...) 및 연대(AD, BC, ...)를 지원하도록 쉽게 확장할 수 있습니다.
• 10000년 안전합니다 ;-) (RFC 3339는 아님)
• 하루 종일 날짜 및 부동 시간 지원(Javascript의 Date.toJSON() 은 지원하지 않음)

RFC 3339에 대한 funroll에서 언급한 것처럼 올바른 정렬은 날짜를 JSON으로 직렬화할 때 실제로 필요한 기능이라고 생각하지 않습니다. 또한 동일한 시간대 오프셋이 있는 날짜-시간에만 해당됩니다.

Marten

출처 : http:www.stackoverflow.com/questions/10286204/what-is-the-right-json-date-format