Chrono Mock앱을 다른 시간대에서 실행하기
엉뚱한 날에 떨어지는 보고서, 한 시간 일찍 울리는 알림, 내일로 읽히는 타임스탬프. 이런 문제의 대부분은 자신이 있지 않은 시간대에서만 나타납니다. 이 도구는 프로세스 하나에 자신만의 오프셋을 주고, 시스템 시간대는 있던 자리 그대로 둡니다.
흔한 해법이 도움이 되지 않는 이유
- Windows 시간대를 바꾸면 모든 것에 영향을 줍니다. 달력, 로그, 회의가 모두 바뀌며, 관리되는 컴퓨터에서는 바꿀 권한이 없을 수도 있습니다.
TZ를 설정하는 방법은 일부 런타임에서는 통하고 다른 곳에서는 통하지 않습니다.GetTimeZoneInformation을 읽는 네이티브 Windows 애플리케이션은 전혀 알아채지 못합니다.- 브라우저 개발자 도구는 웹 페이지의 시간대를 덮어쓰는데, 훌륭하지만 데스크톱 애플리케이션과는 무관합니다.
프로세스 하나에 오프셋 하나
세션은 자신만의 오프셋을 가집니다. 애플리케이션이 Windows에 자신의 시간대를 물으면 그 답을 받고, 컴퓨터의 다른 모든 프로그램은 실제 답을 받습니다.
# 같은 시점을 미국 서부 해안에서 본 모습 chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00 # 시간대만 - 오늘의 실제 날짜에 다른 사람의 시계 chrono run "C:\apps\test.exe" --zone +09:00
계산기는 질문의 나머지 절반, 즉 어떤 시점이 다른 곳에서는 실제로 어떻게 읽히는지에 답합니다. 변환은 순간을 보존하고 벽시계만 바꾸며, 날짜가 엉뚱한 날에 떨어지는 방식이 바로 이것입니다.
$ chrono calc --base 2027-01-15T09:00:00 --zone +01:00 --to-zone -08:00 Chrono Mock - date calculator base: 2027-01-15T09:00:00 step 1: zone -08:00 -> 2027-01-15T00:00:00 result: 2027-01-15T00:00:00 formats: ISO date 2027-01-15 ISO datetime 2027-01-15T00:00:00-08:00 US 01/15/2027 PL 15.01.2027
중부 유럽의 오전 9시는 미국 서부 해안에서는 자정입니다. 같은 순간이지만, 현지 날짜로 묶는 일일 보고서는 실행되는 위치에 따라 다른 날로 분류합니다.
솔직한 제한, 그리고 여기서는 중요합니다
세션 시간대는 서머타임이 없는 고정 오프셋입니다.
+01:00으로 설정한 세션은 시계가 1월을 가리키든 7월을 가리키든 +01:00에 머뭅니다. 따라서 실제 전환을 가로지르는 실행은 그 시간대가 실제로 보여 줄 값에서 한 시간 어긋나며, 앱을 서머타임 전환으로 통과시키는 것은 이 도구가 아직 하지 못하는 일입니다. 날짜 계산기는 짐작하지 않고 그 사실을 밝힙니다.
- 시간대는 스스로를 “Chrono Session”이라고 보고합니다. 어떤 Windows 레지스트리도 모르는 이름입니다. 그 이름을 시간대로 다시 매핑하려는 것, 예를 들어 .NET의
TimeZoneInfo.Local같은 것은 대신 오프셋으로 대체되며, 그것이 올바른 답입니다. 레지스트리 이름을 고집하는 애플리케이션은 찾지 못합니다. - Java는 세션 시간대를 오프셋으로 받아들입니다. 세션 시간대에는 서머타임도 그 뒤의 도시도 없으므로 Java는 오프셋을 따서 이름을 붙입니다. +05:30 세션이면
GMT+05:30입니다. - Chromium과 Electron 모드에서는 페이지도 세션 시간대를 읽습니다. 같은 고정 오프셋입니다. 모든 페이지와 워커가 그 시간대에 놓이고 자신이 읽는 값을 확인합니다. Electron 애플리케이션의 메인 프로세스는 세션이 닿지 않는 Node에서 JavaScript를 실행하므로 실제 시계를 유지합니다.
- 오프셋은 -14:00에서 +14:00까지, 분 단위의 정수입니다. 그 밖의 값은 조용히 감겨 돌지 않고 거부됩니다.
이 중 어느 것이 앱에 해당하는지는 짐작할 것이 아니라 측정할 수 있습니다. 세션이 자신의 커버리지를 보고합니다 →