개발자 도구 · Unix 타임스탬프 변환기
off-by-1000 버그: 날짜가 1월 1970 또는 연도 56000를 표시하는 경우
· 그것이 중요한 이유
타임스탬프 디버깅 개발자 워크플로
밀리초가 예상되는 곳에 초를 전달하는 것(또는 그 반대)은 가장 일반적인 타임스탬프 버그입니다. 이 게시물에서는 각 방향에서 어떻게 보이는지, 언어 사이에 숨어 있는지, 몇 초 안에 잡는 방법을 보여줍니다.
1 1월 1970에 참여한 모든 사용자 — 버그를 알려주는 화면과 완벽하게 올바른 백엔드
1월 1970 근처의 모든 계정을 표시하는 프로필 페이지는 강력한 규모의 증상입니다. 백엔드가 올바른 epoch 초를 반환했을 수 있지만 프런트엔드 코드는 이를 밀리초를 해석하는 Date 생성자에 직접 전달했습니다. 그러면 현재의 숫자는 달력 축에서 1,000배로 줄어듭니다.
상수 연도를 추가하거나 날짜를 교체하여 디스플레이를 패치하지 마십시오. 원시 필드, 해당 API 계약 및 정확한 생성자 호출을 캡처합니다. ToolAcre를 사용하면 두 장치를 모두 강제할 수 있으므로 생산 데이터를 변경하지 않고도 하나의 값을 테스트할 수 있습니다. 알려진 다른 이벤트와 일치하는 판독값은 가능한 경계 오류를 식별합니다.
두 가지 증상 - 1970 1월에 착륙한 밀리초 API에 밀리초가 공급되고, 수만 년 전에 착륙한 API에 밀리초가 공급되었습니다.
밀리초로 해석된 초는 10억 밀리초가 한 세기의 작은 부분에 불과하기 때문에 신기원에 가깝습니다. 역 실수는 1조 밀리초 값을 1조 초로 확장하는데, 이는 종종 일반적인 응용 프로그램 범위를 벗어나는 경우가 많습니다. 두 가지 실패 모두 스케일을 변경하는 동안 숫자를 유지합니다.
출판된 10대 13자리 기사는 이미 현대의 시각적 휴리스틱과 그 한계를 설명합니다. 대신 이 기사에서는 진단 및 예방에 중점을 둡니다. 즉, 명시적인 단위 선택, 독립적인 사건 증거, 생산자의 표현이 소비자의 계약을 충족하는 인터페이스에서의 한 번의 변환입니다.
두 분기 모두 결정적이므로 하나의 Fixture로 증상을 재현할 수 있습니다. 따라서 간헐적인 시계 드리프트 또는 로캘 형식 지정 동작보다 단위 불일치를 더 쉽게 증명할 수 있습니다.
경계는 일반적으로 밀리초 단위의 JavaScript 및 Java, 초 단위의 Unix 도구, Python 및 대부분의 데이터베이스, 그리고 이들 사이의 JSON 페이로드입니다.
이 저장소는 JavaScript Date가 밀리초를 소비하고 ToolAcre가 이를 구성하기 전에 초를 곱한다는 것을 증명합니다. 통합 문서에 명명된 모든 Java, Python, 셸 또는 데이터베이스 API의 기본값을 설정하지는 않습니다. 해당 계약이 사용되는 위치를 확인해야 합니다.
JSON 번호에는 장치 메타데이터가 없습니다. 필드 이름을 `created_at`로 지정하면 서비스 전체에 모호함이 전달됩니다. 이름을 `created_at_s`로 지정하거나 ISO 문자열을 문서화하면 계약을 검토할 수 있습니다. 수신 어댑터는 뷰 전체에 곱셈을 분산시키는 대신 내부 표현으로 한 번 변환해야 합니다.
재사용 가능한 디스플레이 도우미 내부가 아닌 경계 정의 옆에 변환을 작성합니다. 어댑터는 생산자 계약을 알고 있습니다. 일반 포맷터는 이미 정규화된 인스턴스를 수신해야 합니다.
단위 경계는 API에 따라 다릅니다. 이 저장소는 JavaScript 날짜가 밀리초를 사용한다는 것을 증명합니다.
`0`와 같은 약한 픽스처는 0초와 0밀리초가 모두 신기원을 지정하기 때문에 버그를 감지할 수 없습니다. 조작된 작은 값은 그럴듯한 1970 날짜처럼 보일 수도 있습니다. 소비자가 기대하는 것과 동일한 규모를 반환하는 모의 모델은 실제 통합 불일치를 결코 행사하지 않습니다.
0이 아닌 알려진 순간을 선택하고 두 해석을 눈에 띄게 다르게 만듭니다. 단순히 Date 객체가 존재한다는 사실뿐만 아니라 경계에서 표준 ISO 결과를 주장합니다. 밀리초 케이스와 초 케이스를 포함합니다. ToolAcre의 자체 테스트는 바로 이러한 이유로 각 장치에서 1,000,000을 비교합니다.
테스트가 두 척도를 구별하지 못할 때마다 단위 버그가 살아남습니다.
`created_at: 1738578000`을(를) 고려하세요. 초 단위로 강제 적용되면 `2025-02-03T10:20:00.000Z`이 됩니다. 밀리초 단위로 강제하면 `1970-01-21T02:56:18.000Z`가 됩니다. 2025 2월에 생성된 것으로 알려진 배포 기록은 자릿수에만 의존하지 않고 모호성을 해결합니다.
어댑터를 수정하는 동안 알려진 이벤트 옆에 원시 JSON을 유지하세요. 필드가 `1738578000000`인 경우 밀리초 해석은 동일한 순간을 식별합니다. 변환기가 올바른 배율을 적용한 후 동등함을 입증할 수 있더라도 두 값은 하나의 스키마 내에서 상호 교환적으로 허용되어서는 안 됩니다.
알려진 배포 날짜는 독립적인 증거입니다. 그것이 없다면, 더 그럴듯한 출력을 선택하는 것은 제작자가 의도한 것을 확립하기보다는 조사자의 기대를 인코딩할 수 있습니다.
작업된 예: 두 명시적 단위 모두에서 Created_at 값을 테스트합니다.
내구성 있는 복구는 경계에서 시작됩니다. 문서화된 소스 단위를 구문 분석하고 정확히 한 번 변환한 후 유형이 지정되거나 명확하게 이름이 지정된 내부 값을 노출합니다. 스키마 설명, 예제 및 생성된 클라이언트는 접미사 또는 날짜-시간 형식을 유지해야 합니다. 그러면 검토자는 런타임 전에 추가 곱셈을 발견할 수 있습니다.
실제 규모와 고정된 ISO 기대치를 사용하여 회귀 고정 장치를 추가합니다. 생산자가 계약을 맺은 경우 애플리케이션 코드에서 자동 감지를 피하세요. 휴리스틱은 불확실한 레거시 데이터를 조사하기 위한 것입니다. ToolAcre는 감지된 선택 사항에 정확하게 레이블을 지정하므로 추측이 보장된 메타데이터로 가장될 수 없습니다.
여기서 다루지 않는 내용 — 시간대 실수로 날짜가 수십 년이 아닌 시간 단위로 이동됩니다.
시간대 오류는 일반적으로 표시를 시간 단위로 이동시키며 달력상 하루가 지날 수 있습니다. 1,000 요인 오류는 수십 년 또는 수천 년 동안 이동합니다. 진단을 혼합하면 척도가 이미 잘못된 값을 중심으로 오프셋 조정이 권장됩니다. 로컬 포맷을 검사하기 전에 장치를 확인하십시오.
마찬가지로, 잘못된 에포크 출처는 초와 밀리초 모두에서 무의미한 상태로 남아 있을 수 있습니다. 어떤 해석도 알려진 이벤트와 일치하지 않으면 전환을 중지하고 생산자를 조사하세요. 변환기는 가설의 범위를 좁힙니다. 모든 큰 정수가 유닉스 시간임을 증명하지는 않습니다.
연도는 그럴듯하지만 시간은 지속적으로 바뀌는 경우 구역 표시를 조사하십시오. 이러한 증상 척도를 별도로 유지하면 스크린샷에서 근본 원인까지의 경로가 단축됩니다.
요점: 잘못된 단위는 잘못된 세기입니다. Unix 타임스탬프 변환기의 명시된 단위를 사용하여 두 판독값을 동시에 테스트할 수 있는 방법
잘못된 단위는 외관상의 메타데이터가 아닙니다. 즉시 변경됩니다. 1970-무거운 화면과 믿을 수 없을 정도로 먼 연도를 생산자-소비자 이음새를 검사하기 위한 신호로 처리합니다. 가치, 단위 계약 및 알려진 사건은 명백히 합리적인 날짜보다 더 강력한 세 부분으로 구성된 증거를 형성합니다.
변환기를 사용하여 명시적인 판독값을 비교한 다음 선택한 척도를 이름, 유형 및 테스트로 인코딩합니다. 목표는 소프트웨어가 더 영리하게 추측하도록 가르치는 것이 아닙니다. 사용자에게 날짜를 생성하는 경로에서 추측을 제거하는 것입니다.
그러면 코드 검토를 통해 각 경계에서 하나의 정확한 질문(어떤 단위가 들어오고 어떤 단위가 나가는가?)을 물을 수 있습니다. 이는 특정 자릿수를 인식하는 것보다 더 안정적입니다.