"올바른"JSON 날짜 형식

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 가 옳습니다.

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

혜택

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

결론

나는 사람이 읽을 수있는 형식 (ISO-8601 문자열)이 80 %의 사용 사례에 유용하고 더 편리 하다는 것을 이해합니다. 실제로 응용 프로그램이 있다면 날짜를 ISO-8601 문자열로 저장 하지 말라고 지시 해서는 안됩니다 이해 하지만 , 특정 값을 확실히 보장해야하는 보편적으로 허용되는 전송 형식의 경우 어떻게 모호성을 허용하고 그렇게 많은 검증이 필요한가?

JSON 자체에는 날짜 형식이 없으므로 누구나 날짜를 저장하는 방법을 신경 쓰지 않습니다. 그러나이 질문에는 javascript 태그가 지정되어 있으므로 javascript 날짜를 JSON에 저장하는 방법을 알고 싶다고 가정합니다. JSON.stringify메소드에 날짜를 전달 하면 Date.prototype.toJSON기본적으로 사용 되며 Date.prototype.toISOString( MDN on 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

나는 또한 유용 사용하는 발견 reviver의 매개 변수 JSON.parse( JSON.parse에 MDN을 내가 JSON 문자열을 읽을 때마다 자동으로 자바 스크립트 날짜에 ISO 문자열을 다시 변환).

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

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

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

그래서 당신은 날짜가 기본 방법이 참조로 toJSON, return이 형식으로 쉽게 변환 할 수 있습니다 Date다시를 ...

Sharepoint 2013에서 JSON으로 데이터를 가져 오면 날짜를 날짜 전용 형식으로 변환하는 형식이 없습니다. 해당 날짜는 ISO 형식이어야합니다.

yourDate.substring(0,10)

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

"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 (날짜); // 수 1 월 01 2014 13:28:56 GMT- 1000 (하와이 표준시)

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

Kotlin을 사용하는 경우 문제가 해결됩니다. (MS Json 형식)

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

그것은 구문 분석 서버와 함께 작동합니다

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

이것에 대한 정답은 단 하나 뿐이며 대부분의 시스템은 잘못 생각합니다. 에포크 (epoch) 이후 밀리 초 (64 비트 정수)입니다. 표준 시간대는 UI와 관련이 있으며 앱 계층 또는 DB 계층에는 비즈니스가 없습니다. DB가 표준 시간대를 신경 쓰는 이유는 무엇입니까, 64 비트 정수로 저장한다는 것을 알면 변환 계산을 수행하십시오.

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

다음 코드가 나를 위해 일했습니다. 이 코드는 날짜를 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);

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

{
"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으로 직렬화 할 때 실제로 필요한 기능이라고 생각하지 않습니다. 또한 동일한 시간대 오프셋을 가진 날짜-시간의 경우에도 마찬가지입니다.