JSON에 날짜/시간을 저장하는 가장 좋은 방법은 무엇입니까?

JSON에 날짜/시간을 저장하는 가장 좋은 방법은 무엇입니까?

JSON은 처음이라 JSON 사양을 검토해보니 날짜 및 시간에 대한 데이터 타입이 없다는 것을 알게 되었습니다.몇 가지 조사를 해 본 결과, 몇 가지 제안이 있었습니다.그 중 하나는 UNIX 타임스탬프를 사용하는 것입니다.그게 가장 간단한 방법인가요?앞으로 문제가 생길까요?

ISO 8601 날짜를 사용하는 것이 좋습니다.특히 이 포맷은

2014-03-12T13:37:27+00:00

는 많은 프로그래밍 언어를 통해 휴대할 수 있습니다.

편집:

JSON은 다음 유형만 인식합니다.

string
number
object
array
true
false
null

날짜 및 날짜는 널리 사용되는 형식으로 문자열로 저장하는 것이 좋습니다.

최적의 답변은 그 날짜/시간이 사용되는 상황에 따라 다르다고 생각합니다.

TL/DR;

올바른 형식은...에 따라 달라집니다.

• 데이터 사용 방법의 컨텍스트(아래 예 참조)
• 사용자 또는 코드가 json을 사용하고 있는지, 프로그래밍 언어 또는 라이브러리가 특정 형식을 쉽게 지원하는지 여부.

json number(유닉스 타임스탬프)를 사용하고, 유스케이스에 따라 유저 타임존 또는 개별적으로 격납된 단일 「렌더 타임존」(json 문자열)을 조합하는 것을 추천합니다.이것에 의해, 가장 관련성이 높은 날짜/시간 렌더링을 유저에게 제공할 수 있어 유저의 장소/장소에 따라 다른 날짜/시간 형식을 간단하게 사용할 수 있습니다.

인간에 대한 json-readability가 중요한 경우 ISO 문자열 형식을 사용할 수도 있지만 사용자에게 친숙한 날짜/시간을 최대한 유연하게 렌더링할 수 있도록 코드에서 구문 분석 및 시간대 변환을 수행할 수도 있습니다.

경고 이러한 타임스탬프를 손으로 작성하는 경우, 그것들을 망치지 마십시오.다른 시간대에 대한 오프셋은 연중 다른 지역의 다른 날짜에 변경되며, 특정 지역/날짜에 대해 잘못된 오프셋을 지정하면 타임스탬프가 정확한 시점을 나타내지 않습니다.해석하고 포맷하면 잘못된 시간이 표시되어 문제가 발생할 수 있습니다.

JSON 날짜를 쉽게 읽을 수 있도록 하려면

즉, 인간이 직접 json을 읽고 날짜/시각에 의미를 부여하고 싶은 경우.

이 경우 @Ribtoks의 답변이 가장 좋을 것입니다.날짜/시간이 사용자와는 다른 시간대에 저장되어 있는 경우, 사용자가 혼동하거나 날짜/시간을 올바르게 해석하기 위해 머릿속에서 시간대 변환을 수행해야 할 수 있습니다.

수동 편집에 대한 유혹과 구문 분석 오류로 이어질 수 있는 포맷 오류.또한 UTC 오프셋이 올바르지 않은 경우(특정 지역/날짜에 대한 오프셋/시간이 잘못됨) 포맷 후 사용자에게 잘못된 날짜/시간이 표시됩니다.

json이 단순한 데이터 스토리지이며 날짜/시간이 코드로 렌더링되는 경우

사용자-로컬 날짜/시간 형식

즉, 특정 시간(날짜/시간)을 로컬 시간대에 있는 사용자에게 표시하려고 합니다.

이 경우 특정 순간을 나타내는 날짜/시간 데이터와 더불어 특정 사용자에게 "올바른" 시간대를 식별할 수 있는 방법이 필요합니다(다른 항목).

할 수 날짜를 해석 JSON 날짜/시간 데이터).America/Denver ★★★★★★★★★★★★★★★★★」Europe/Berlin를 사용하면, 사용하기 쉬운 형식으로 인쇄할 수 있습니다., 그럼 ㄴㄴㄴ데를 한 번 보세요.moment-timezone라이브러리로 이동합니다.

「 」 、 「 」 、 「 」:
December 31, 2020 8:00 PM America/Denver

January 1, 2021 4:00 AM Europe/Berlin

이러한 행동은 소셜 미디어나 블로그의 투고, 유저가 자신의 현지시간으로 언제 출판되었는지를 알고 싶어 하고, 저자의 타임 존에 개의치 않는 메시지 보드 등에서는 바람직하다.

이 경우 날짜/시간을 해석/포맷해야 하기 때문에 보통 날짜/시간을 unix 타임스탬프에 저장합니다(정수).json 번호).

다른 타임존에 있는 사용자의 새로운 날짜/시간 문자열을 포맷하기 위해 내장된 타임존을 포함한 문자열 타임스탬프를 해석하는 것보다 숫자를 추출하여 계산하는 것이 계산적으로 간단합니다.

이벤트/장소-로컬 날짜/시간 형식

즉, 특정 시간대의 사용자에게 특정 순간(날짜/시간)을 표시하려고 합니다.

예: 베를린에서 열리는 (직접) 음악 콘서트 날짜/시간.만약 여러분이 런던에서 티켓을 사는 콘서트 관람객들이 있다면, 베를린에서 열리는 행사에 참석하기 때문에 런던 시간으로 몇 시에 콘서트가 시작하는지 보여주는 것은 혼란스러울 것이다.

이는 위의 "User-Local" 사례와 동일한 경우입니다.단, 각 사용자에 대해 다른 시간대 내의 특정 순간을 포맷/렌더하는 것이 아니라 단일 특정 "이벤트 로케이션 타임존"으로 날짜/시간을 렌더링합니다.

따라서 특정 날짜/시간을 저장할 뿐만 아니라 해당 날짜/시간을 렌더링할 시간대도 저장해야 합니다.

날짜/시간을 문자열로 미리 포맷할 수 있지만, 이를 통해 프로그래밍 방식으로 날짜 형식을 변경할 수 있는 옵션이 줄어듭니다.예를 들어 이벤트 로컬 시간대를 사용하되 국가별로 다른 날짜/시간 형식을 사용할 수 있습니다.

예: 2020년 11월 25일 오후 7시에 베를린에서 열리는 콘서트입니다.같은 시간대에, 같은 시간대지만 다른 형식입니다.

미국
11/25/20 7:00PM Europe/Berlin
독일.
25.11.20 19:00 Europe/Berlin
영국
25/11/20 19:00 Europe/Berlin

따라서 이 경우 날짜/시간을 json 번호(unix timestamp)로 저장하고 이벤트 시간대를 해당 타임스탬프 옆에 문자열로 저장합니다.이것에 의해, 해석/타임 존 변환 계산이 간단하게 됩니다.그런 다음 사용자의 특정 날짜/시간 형식 선호도(브라우저 로케일, 사용자 프로파일 등)를 파악해야 합니다.(이 질문의 범위외)

시간대/오프셋을 잘못 알고 있는 일화

동료의 컴퓨터에 잘못된 타임존이 설정되어 있었습니다(그 결과 자신의 위치에 대한 UTC 오프셋이 잘못되어 있었습니다.

이 문제를 해결하기 위해 네트워크 시간을 비활성화하고 잘못된 시간대에 맞게 컴퓨터 시계를 수동으로 조정했습니다.

그가 특정 시간에 회의 초대장을 보낼 때, 초대장에는 그 시간대와 시간대가 포함됩니다.이는 물론 시간대 경계를 넘어 콜이 있을 때 중요하기 때문에 모든 사람이 로컬 시간으로 회의를 보고 동시에 통화할 수 있습니다.제 동료들의 경우, 물론 이 회의들은 다른 시간대로 보내졌습니다.

그는 모든 사람들이 한 시간씩 회의에 참석하지 못하자 화가 나서 어떻게 3시로 일정을 잡았는지 보여주었지만 우리는 모두 4시로 초대받았다.

이야기의 사기...일반적으로 해킹은 결국 역효과를 일으키기 때문에 올바른/불확실한 순간을 시간 내에 저장해 두는 것이 매우 중요합니다.처음에 올바른 시점을 저장한 경우에만 나중에 표시되는 시간대/형식을 언제든지 변경할 수 있습니다.

폼 입력(예: YYY-MM-DD를 제공하는 달력 보기 및 HH를 제공하는 달력 보기)을 다룰 때 기본적인 순간을 정확하게 파악하는 것이 가장 중요합니다.MM) 사용자의 이러한 날짜/시간 입력 문자열이 사용 사례에 따라 시간대 컨텍스트로 해석되도록 해야 합니다.

물론 String은 JSON에 저장해야 합니다.하지만 날짜를 필터링하려고 합니다.숫자도 "125"와 같은 문자열로 저장할 수 있으며 125로 다시 변환할 때 유용합니다.즉, 예를 들어 필터링을 위해 날짜 번호를 사용자 정의하려는 경우:long type을 사용하여 비트 연산을 수행합니다.https://docs.oracle.com/javase/tutorial/java/nutsandbolts/op3.html

• 4096-1년까지 12비트를 YYY용으로 예약합니다.
• (0-11)이면 충분하므로 MM용으로 4비트를 예약합니다.
• 요일이 (1~31)이므로 DD용으로 5비트를 예약합니다.

64비트까지 몇 시간, 몇 분 동안 계속 비트를 예약할 수 있습니다.이 경우 DD/MM/YYY는 21비트입니다.이 aproach를 사용하면 @Clay Ferguson에 동의하고 지도에서 "<" 및 ">"의 관점에서 매우 쉽고 빠르게 키셋을 필터링할 수 있습니다.

원시 JSON의 사람이 읽을 수 있는 것보다 메모리(및 Disk 공간)의 효율성에 더 관심이 있는 경우 정수(즉, 날짜의 밀리초 값)로 저장하는 것이 가장 좋습니다.또, 공간 절약용으로 최적화하는 경우는, 그 정수를 Base64 로 인코딩 해, Base64 문자열을 JSON 문자열로서 JSON 에 보관 유지할 수 있습니다.16진수를 말하는 것도 아닙니다.만약 10진수가 아닌 것으로 인코딩을 하고 있다면 base64로 이동하는 것이 좋기 때문입니다.즉, base64 위의 16진 부호화에 대한 베니핏은 없으므로 base64로 합니다.

언급URL : https://stackoverflow.com/questions/22354899/what-is-the-best-way-to-store-a-date-time-in-json