개발자 도구 · Unix 타임스탬프 변환기
음수 Unix 타임스탬프: 1970 이전 날짜가 표시되는 방식
· 작동 방식
타임스탬프 유닉스 시간 데이터 형식
Unix 시간은 1970부터 앞으로 계산되지만 뒤로도 계산됩니다. 이 게시물에서는 음수 시대의 의미, −1이 1969의 마지막 초가 되는 방법, 양수 값을 가정하는 시스템이 중단되는 위치에 대해 설명합니다.
마이너스 기호가 있는 생년월일 — 1965에 태어난 사용자가 음의 정수로 저장되어 있고 이를 오류로 처리한 코드
1970 이전에 태어난 사람의 기록에는 음의 Unix 타임스탬프가 합법적으로 포함될 수 있습니다. 모든 선행 빼기 기호를 거부하면 표현 선택이 데이터 손실 버그로 변환됩니다. ToolAcre의 파서는 선택적 기호를 허용하며 `fromEpoch`은 0 미만으로 해석된 밀리초 값을 유효하지 않은 것으로 처리하지 않고 `beforeEpoch`로 표시합니다.
그런 다음 디스플레이는 해당 순간이 Unix 시대 이전임을 설명하는 메모를 추가합니다. 이는 검토자가 특이한 기호를 볼 수 있도록 유지하므로 날짜를 자동으로 렌더링하는 것보다 강력합니다. 업스트림 스키마가 부정을 금지하는 경우 실패는 0의 양쪽에 개수를 매핑하는 산술이 아니라 해당 스키마 또는 마이그레이션에 속합니다.
부호 있는 정수 및 시대 — time_t가 부호 있는 이유와 −1 및 −86400에 해당하는 내용
0은 1970-01-01T00:00:00.000Z입니다. 저장소 테스트는 −1초가 바로 앞선 순간인 `1969-12-31T23:59:59.000Z`임을 증명합니다. 마찬가지로 −86,400 초는 0 이전 고정 POSIX 하루입니다. 부호 있는 산술은 오래된 레코드에 대해 두 번째 에포크를 요구하는 대신 축을 연속적으로 만듭니다.
개요에서는 서명된 저장소를 `time_t`에 귀속시켰지만 이 코드는 모든 플랫폼에서 사용되는 설계 기록이나 유형을 설정하지 않습니다. 더 좁은 증거만으로도 충분합니다. JavaScript 숫자는 음수일 수 있고, 감지는 절대 크기를 사용하며, 날짜는 결과 형식을 지정할 수 있습니다. 변환기가 허용하는 입력과 별도로 생성 필드의 선언된 유형을 설명합니다.
매번 time_t가 해당 유형을 선택한 이유를 밝히지 않고 0을 중심으로 하는 서명된 에포크 산술
음수 값은 양수 값과 동일한 단위 구별을 유지합니다. `−1000`초는 에포크 전의 1,000초를 가리키는 반면, `−1000`밀리초는 에포크 전의 1초만을 가리킵니다. 자동 감지는 크기가 1011 미만이므로 두 가지를 모두 초로 처리하므로 짧은 사전 에포크 밀리초 수를 지정하려면 명시적인 밀리초 선택이 필요합니다.
이것은 숫자 세기 민속의 구체적인 실패입니다. 빼기 기호와 네 자리 숫자를 보는 개발자는 외관상 장치를 추론할 수 없습니다. 소스 계약을 사용하여 선택기를 선택하고 단위 노트를 검사합니다. ToolAcre의 크기 규칙은 일반적인 데이터에 대한 기본값이며 1970에 가까운 기록 값에 대한 메타데이터를 대체하지 않습니다.
음수 값이 실패하는 경우 - −1을 센티넬로 사용하는 시스템, 서명되지 않은 저장소, 고정하는 날짜 선택기 및 이를 거부하는 언어
변환기 외부에서 `−1`은 때때로 누락된 값 센티널로 예약되며 부호 없는 열은 음의 순간을 보존할 수 없습니다. 이는 일반적인 설계 가능성이지만 저장소는 특정 데이터베이스, 날짜 선택기 또는 언어가 어떻게 작동하는지 인증할 수 없습니다. 보관 날짜를 이동하기 전에 실제 경계를 테스트하십시오.
유용한 프로브에는 세 가지 값, 즉 null 또는 문서화된 누락 마커, −1 및 확실히 오래된 날짜가 포함되어 있습니다. 이전 값이 유지되는 동안 −1이 사라지면 센티널 처리가 관련됩니다. 모든 네거티브가 실패하면 유형과 유효성 검사를 검사하십시오. 1970년을 추가하거나 절대값을 취하여 증상을 "수정"하지 마십시오. 둘 다 서로 다른 순간을 생성하기 때문입니다.
작업 예: −14182940 — 산술을 UTC 및 그리니치 서쪽 지역 영역의 7월 1969 날짜로 변환
−14,182,940초 동안 해당 에포크에서 시작하여 뒤로 164 전체 86,400초 일을 이동하고 13,340초를 남깁니다. 나머지는 3시간, 42분, 20초입니다. 결과 UTC 판독값은 `1969-07-20T20:17:40.000Z`이며, 이 기사를 위해 특별히 여기에서 선택한 순간입니다.
UTC 서쪽의 지역 판독값은 더 빠른 벽시계 시간이나 다른 날짜를 표시할 수 있지만 정확한 결과는 브라우저 영역 및 Intl 규칙에 따라 다릅니다. 보편적인 답변을 게시하기보다는 패널에서 읽어보세요. 고정된 확인은 ISO 행입니다. 로컬 행은 동일한 음수 수에 대한 환경 주석입니다.
작업된 예: 검증 가능한 UTC 산술을 사용하여 −14,182,940 변환
ToolAcre는 해석된 값을 소스에 명시된 날짜 범위인 ±8.64×101⁵ 밀리초와 비교하여 확인합니다. 또한 −2,208,988,800초가 `1900-01-01T00:00:00.000Z`로 변환되었음을 증명합니다. 이러한 사실은 경로가 1970 이전에 도달했음을 보여 주며 모든 스토리지 시스템이 동일한 범위를 전달할 수 있다는 의미는 아닙니다.
서명된 32비트 필드는 JavaScript 날짜보다 수학적 간격이 더 좁지만 숫자를 붙여넣을 때 변환기는 필드 너비를 검사하지 않습니다. 감사 시 소스 유형을 유지합니다. 성공적인 브라우저 변환은 다른 곳의 펌웨어, SQL 열 또는 바이너리 프로토콜을 통한 안전한 왕복이 아니라 여기서 표현 가능성을 보여줍니다.
변환기의 기간이 알려져 있습니다. 외부 32비트 제한은 스토리지 유형에 따라 다릅니다.
숫자를 JavaScript 날짜로 변환해도 수세기 전에 모든 위치에서 실제로 인쇄된 민간 달력이 재구성되지는 않습니다. 구현에서는 플랫폼의 날짜 모델을 사용하고 ISO 표현을 반환합니다. 여기에는 달력 개혁을 위한 역사적 달력 선택기, 로케일 아카이브 또는 다큐멘터리 소스가 포함되어 있지 않습니다. 이러한 주장은 의도적으로 존재하지 않습니다.
최신 소프트웨어 기록의 경우, 예측 기계 표현은 여전히 필요한 계약일 수 있습니다. 계보, 법적 역사 또는 기록 보관의 경우 원본 기록 날짜와 파생된 시대와 함께 달력 컨텍스트를 보존합니다. 편리하게 정렬 가능한 숫자는 변환이 해결할 수 없는 불확실성을 지워서는 안 됩니다.
달력 기록 주장은 이 변환기의 증거 외부에 있습니다.
음수는 오류 범주가 아닌 신기원 축의 방향입니다. ToolAcre는 이를 구문 분석하고 크기별로 동일한 초 또는 밀리초 규칙을 적용하고 에포크 이전과 같이 결과에 플래그를 지정합니다. 이러한 동작을 통해 검토자는 합법적인 이전 인스턴스를 다른 곳의 감시 또는 서명되지 않은 스토리지 오류와 구별할 수 있습니다.
1970 이전 데이터를 감사할 때 기호를 해석하기 전에 단위, 소스 유형 및 결측값 규칙을 명시하십시오. 그런 다음 ISO 결과를 알려진 기록과 비교합니다. 부호만으로도 의미 있는 산술이 됩니다. 주변 스키마는 생산자가 해당 산술을 의도했는지 또는 동일한 숫자를 제어 값으로 사용했는지 여부를 결정합니다.