개발자 도구 · Unix 타임스탬프 변환기
브라우저가 Date 및 Intl을 사용하여 신기원을 현지 시간으로 변환하는 방법
· 작동 방식
타임스탬프 자바스크립트 브라우저 API
브라우저 변환기에는 자체 서버 시계나 시간대 데이터베이스가 없습니다. 이는 운영 체제에서 지원하는 Date 개체와 Intl API에 의존합니다. 이 게시물에서는 해당 파이프라인과 그 한계에 대해 설명합니다.
브라우저는 어디에서 '로컬'을 가져오나요? — 같은 방에 있는 노트북과 전화기에 같은 시대가 다르게 표시됨
서로 옆에 있는 두 장치는 구성된 로컬 영역이 다를 때 한 시대를 다르게 렌더링할 수 있습니다. 노트북과 휴대폰 간에 정수는 변경되지 않습니다. 각 브라우저는 동일한 순간을 구성한 다음 자체 환경에 대한 로컬 달력 필드를 제공합니다. 따라서 "지역적"은 시대 내부에 있는 속성이 아니라 독자를 설명합니다.
ToolAcre는 로컬 행에 `Intl.DateTimeFormat().resolvedOptions().timeZone` 레이블을 지정하여 해당 종속성을 표시합니다. 한 시계 시간을 나타내는 스크린샷과 다른 시계 시간을 나타내는 서버 로그는 둘 다 충실한 판독값일 수 있습니다. 먼저 UTC 행을 비교하십시오. UTC 출력과 일치하면 기본 순간이 아닌 프레젠테이션이 다르다는 것을 알 수 있습니다.
날짜는 밀리초가 걸립니다 — 생성자의 계약, 초에 1000을 곱해야 하는 이유 및 날짜가 나타낼 수 있는 범위
JavaScript `Date`는 에포크로부터 밀리초를 수신합니다. ToolAcre의 `fromEpoch`은 입력된 초에 1,000를 곱하고 객체를 구성하기 전에 밀리초의 입력을 변경하지 않고 그대로 둡니다. 1,717,243,200을 `new Date`에 직접 전달하는 것은 6월 2024이 아니라 1970 이후 약 20일을 의미하기 때문에 해당 변환은 명시적입니다.
구현은 형식화하기 전에 무한한 숫자와 ±8.64×101⁵ 밀리초를 초과하는 해석된 값을 거부합니다. 해당 제한은 데이터베이스나 운영 체제 시계가 아닌 소스에 명명된 날짜 범위에서 비롯됩니다. 선택기를 변경하면 값이 경계를 넘어 이동할 수 있으므로 오류를 통해 어떤 단위가 적용되었는지도 알 수 있습니다.
UTC 접근자 대 로컬 접근자 - getUTCHours 및 getHours, 그리고 엔진이 오프셋을 적용하는 방법
ToolAcre는 `getUTCHours` 및 `getHours`이 있는 필드를 추출하지 않습니다. 개요의 접근자 표현은 구현보다 더 구체적입니다. `Intl.DateTimeFormat`에 날짜 형식을 `timeZone: "UTC"`로 한 번, 영역 재정의 없이 한 번 지정하도록 요청합니다. 두 호출 모두 동일한 밀리초 값을 수신하므로 어느 쪽도 이벤트 자체를 이동할 수 없습니다.
디버깅할 때 이러한 구별이 중요합니다. 초 및 밀리초 행이 생산자와 일치하지만 로컬 레이블이 당신을 놀라게 하는 경우, 에포크에 시간을 추가하는 대신 브라우저 영역을 검사하십시오. 수동 오프셋 산술은 다른 순간을 생성한 다음 포맷터가 로컬 규칙을 다시 적용하도록 하여 전형적인 이중 조정 오류를 생성합니다.
UTC 및 로컬 형식은 엔진에 하나의 날짜에 대한 두 가지 판독값을 요청합니다.
변환기는 브라우저에 `resolvedOptions().timeZone`을 요청한다는 것을 증명할 수 있습니다. 특정 엔진이 운영 체제, 번들 데이터 또는 다른 플랫폼 계층에서 모든 시간대 규칙을 얻었는지 여부는 증명할 수 없습니다. 소스는 의도적으로 해당 기계를 엔진 책임으로 취급하고 영역 쿼리가 실패할 경우 "현지 시간"이라는 문구로 대체합니다.
이 증거 경계는 유용합니다. 결과의 명명된 영역은 브라우저의 현재 선택을 식별하지만 시간대 데이터베이스에 대한 버전 보고서는 아닙니다. 두 환경의 이전 날짜가 일치하지 않는 경우 브라우저, 운영 체제 및 표시된 영역을 기록합니다. 변환기는 관측값을 제공합니다. Intl 뒤에 있는 데이터 패키지를 진단하지 않습니다.
브라우저는 로컬 영역을 보고하지만 규칙 소스는 구현 세부정보로 유지됩니다.
ISO 행의 경우 `toISOString()`는 후행 Z와 소수 세 자리가 있는 UTC 문자열을 제공합니다. 사람이 읽을 수 있는 UTC 및 로컬 행은 숫자 연도, 약식 월, 두 자리 일 및 24시간 시계가 포함된 영국 영국 포맷터를 사용합니다. 포맷터는 또한 `shortOffset`를 요청하여 렌더링된 각 행에 적용 가능한 오프셋 부분을 만듭니다.
이러한 선택은 콘솔에서 `Date.toString()`을 복사하는 것이 동등한 증거가 아닌 이유를 설명합니다. 정확한 구문은 로케일에 따라 다르며 이 도구의 출력 계약 외부에 있습니다. ToolAcre는 디스플레이 옵션을 수정하는 동시에 실제 로컬 영역이 달라질 수 있도록 허용합니다. 다른 시스템에서 기계가 읽을 수 있는 안정적인 비교가 필요한 경우 ISO 값을 복사하세요.
작업 예: 1개 에포크, 3개 출력 — UTC ISO 문자열, 로컬 형식의 시간 및 getTimezoneOffset의 분 단위 오프셋
1,717,243,200을 입력하고 초를 선택합니다. 곱셈은 1,717,243,200,000 밀리초를 생성하며, 테스트에서는 이를 `2024-06-01T12:00:00.000Z`로 설정합니다. UTC 행 형식은 UTC로 즉시 표시됩니다. 로컬 행은 브라우저 영역에서 동일한 날짜 형식을 지정하고 해당 영역의 이름을 지정합니다. 초 및 밀리초 행은 두 숫자 형식을 모두 유지합니다.
정확한 로컬 시계와 오프셋은 예제를 실행하는 장치에서 읽어야 합니다. 여기에 하나를 게시하면 모든 독자가 동일한 영역을 가지고 있는 것으로 가정합니다. 이것이 바로 이 작업된 검사가 ISO 어설션을 고정된 결과로 사용하고 로컬 출력을 관찰된 값으로 처리하는 이유입니다. ISO가 다른 경우 위치 설정을 조사하기 전에 선택한 장치를 다시 방문하십시오.
작업된 예: 한 시대, ToolAcre가 실제로 노출하는 세 가지 출력
이 경로는 임의의 세 번째 영역에 대한 선택기를 제공하지 않습니다. `formatInZone`은(는) 내부적으로 영역을 허용할 수 있지만 패널에서는 이를 UTC 및 브라우저 기본값으로만 호출합니다. 사용자가 도쿄, 나이로비 또는 토론토를 선택할 수 있다고 주장하는 기사에서는 Intl이 다른 곳에서 이러한 형식을 지원할 수 있음에도 불구하고 제공되지 않는 인터페이스를 설명합니다.
또한 달력 선택, 로케일 선택 또는 시간대 데이터베이스 개정판을 노출하지 않습니다. 사무실 간 변환의 경우 에포크를 기준으로 유지하고 문서화된 인터페이스 이름이 대상 영역인 도구를 사용합니다. 여기서는 더 좁은 약속이 중요합니다. 즉, 로컬 환경 옆의 범용 UTC이며 로컬의 의미를 결정하는 숨겨진 서버가 없습니다.
요약: 브라우저는 시계이자 지도책입니다. 그리고 Unix 타임스탬프 변환기가 이를 사용하여 서버 없이 UTC와 로컬을 나란히 표시하는 방법
브라우저는 산술 엔진과 프레젠테이션 환경의 역할을 모두 수행합니다. ToolAcre는 단위를 확인하고 하나의 날짜를 생성하고 표준 ISO 값을 요청한 다음 UTC와 로컬 판독값을 나란히 형식화합니다. 해당 단계에는 원격 변환 서비스가 필요하지 않으며 표시된 장치는 1,000 요소 결정을 검토할 수 있도록 유지합니다.
장치 간에 출력이 일치하지 않는 경우 ISO 행, 단위 메모 및 명명된 로컬 영역을 순서대로 비교합니다. 이 세 가지 관찰은 순간, 규모 및 표현을 구분합니다. 현지 시계를 진실의 근원으로 취급하면 세 가지 질문이 모두 하나로 축소되고 시청자가 구역을 변경할 때마다 올바른 변환이 잘못된 것처럼 보이게 됩니다.