시간대 불일치: 웹에서 가장 값싼 일관성 검사
웹사이트가 실행할 수 있는 모든 일관성 검사 중에서 시간대 비교가 가장 값쌉니다. JavaScript 호출 한 번과 서버가 이미 하고 있는 조회 한 번이면 됩니다. 또한 계정이 한 번 더 검토받는 가장 흔한 이유 중 하나이기도 합니다.
시간대 두 개, 출처 두 곳
첫 번째 시간대는 주소에서 옵니다. 서버는 요청이 어디서 왔는지 알고, 지오로케이션 데이터베이스로 그 주소를 지역과 시간대에 매핑합니다. 파리에서 접속했다면 Europe/Paris입니다. 이는 서버에서 일어나는 일이며 브라우저는 관여할 수 없습니다.
두 번째는 브라우저에서 옵니다. Intl.DateTimeFormat().resolvedOptions().timeZone은 운영체제에 설정된 IANA 이름을 반환하고, new Date().getTimezoneOffset()은 현재 UTC 오프셋을 반환합니다. 컴퓨터가 베를린으로 설정되어 있다면 패킷이 어디서 왔든 페이지는 Europe/Berlin을 봅니다.
두 값이 다른 이유
정당한 이유로는 여행, 시계의 지역 설정을 바꾼 적 없는 노트북, 다른 나라에서 나가는 기업 네트워크가 있습니다. 사이트가 신경 쓰는 이유는 프록시입니다. 브라우저는 한 나라에 있는데 주소는 다른 나라이고, 시계에 대해서는 아무도 생각하지 않은 경우입니다. 파리와 베를린은 오프셋이 같으므로 오프셋만 보면 일치하지만, IANA 이름은 일치하지 않습니다. 이름을 비교하는 검사는 이를 잡아내며, 그래서 진단 도구는 숫자 오프셋이 아니라 브라우저의 이름과 주소의 이름을 모두 보여 줍니다.
불일치가 의미하는 것
그것만으로는 결정적인 의미가 없습니다. 실제 사람들도 많이 겪습니다. 하지만 값싼 신호이고, 점수 시스템은 값싼 신호들을 더해 갑니다. 불일치에 호스팅으로 분류된 주소와 제3의 장소에 있는 WebRTC 후보가 더해진 경우는 불일치 하나만 있는 경우와는 다른 이야기입니다.
두 값을 일치시키기
일관된 결과를 얻는 방법은 두 가지입니다. 운영체제의 시간대를 주소에 맞추는 방법은 효과가 있지만, 여러 프로필이 서로 다른 주소를 쓸 때는 번거롭습니다. 또는 브라우저 프로필이 보고하는 시간대를 직접 덮어쓰게 하는 방법이 있으며, 전용 브라우저가 이렇게 합니다. 프로필의 시간대가 실행에 쓰이는 주소를 따라가므로 두 이름이 자동으로 일치합니다. 두 번째 방식은 현재 오프셋, 서머타임 전환, 현지화된 날짜 문자열까지 모두 다뤄야 합니다. 스크립트가 이 모든 것을 비교할 수 있기 때문입니다. Europe/Paris를 보고하면서 날짜는 베를린 오프셋으로 포맷하는 프로필은 모순을 옮겨 놓았을 뿐입니다.
리포트에서 볼 것
“Time zone based on IP”와 “Time zone”을 나란히 보여 주고 서로 다르면 표시해 주는 진단 도구는 사이트의 검사와 정확히 같은 일을 합니다. 일치하면 검사를 통과합니다. 일치하지 않으면 어느 쪽을 바꿔야 하는지 알게 됩니다. 어느 쪽이든 유용한 것은 비교 자체이지 거기에 붙은 점수가 아닙니다.
