[datetime] 일광 절약 시간제 및 시간대 모범 사례 [닫기]

나는이 질문과 그에 대한 답변을 일광 절약 시간, 특히 실제 변화를 다루는 데 대한 결정적인 가이드로 만들고자합니다.

추가해야 할 것이 있으면 수행하십시오.

많은 시스템은 정확한 시간을 유지하는 데 의존하며, 일광 절약으로 인해 시간이 변경되어 시계가 앞뒤로 이동하는 문제가 있습니다.

예를 들어, 주문 시간에 따라 주문 처리 시스템에 비즈니스 규칙이 있습니다. 시계가 변경되면 규칙이 명확하지 않을 수 있습니다. 주문 시간을 어떻게 유지해야합니까? 물론 무수히 많은 시나리오가 있습니다-이것은 단지 예시적인 시나리오입니다.

  • 일광 절약 문제를 어떻게 해결 했습니까?
  • 어떤 가정이 솔루션의 일부입니까? (여기서 문맥을 찾으십시오)

중요하지 않은 경우 더 중요합니다.

  • 작동하지 않는 것은 무엇입니까?
  • 왜 작동하지 않습니까?

프로그래밍, OS, 데이터 지속성 및 기타 관련 문제에 관심이 있습니다.

일반적인 답변은 훌륭하지만 특히 하나의 플랫폼에서만 사용할 수있는 경우 세부 정보를보고 싶습니다.



답변

답변 및 기타 데이터 요약 : (추가하십시오)

하다:

  • 정확한 순간을 언급 할 때마다 일광 절약 시간의 영향을받지 않는 통합 표준에 따라 시간을 유지하십시오. (GMT 및 UTC는 이와 관련하여 동일하지만 UTC라는 용어를 사용하는 것이 좋습니다. UTC는 Zulu 또는 Z 시간 이라고도 합니다.)
  • 대신 현지 시간 값을 사용하여 시간을 유지하기로 선택한 경우 UTC에서이 특정 시간에 대한 현지 시간 오프셋 (이 오프셋은 연중 변경 될 수 있음)을 포함시켜 나중에 타임 스탬프를 명확하게 해석 할 수 있습니다.
  • 경우에 따라 UTC 시간과 동등한 현지 시간을 모두 저장해야 할 수도 있습니다 . 종종 두 개의 별도 필드로 수행되지만 일부 플랫폼 datetimeoffset은 단일 필드에 둘 다 저장할 수 있는 유형을 지원 합니다.
  • 타임 스탬프를 숫자 값으로 저장하는 경우 Unix 시간을 사용하십시오. 이는 1970-01-01T00:00:00Z윤초를 제외한 전체 초 수입니다 . 더 높은 정밀도가 필요한 경우 대신 밀리 초를 사용하십시오. 이 값은 표준 시간대 조정없이 항상 UTC를 기반으로해야합니다.
  • 나중에 타임 스탬프를 수정해야 할 경우 원래 시간대 ID를 포함시켜 오프셋이 기록 된 원래 값에서 변경되었는지 확인하십시오.
  • 향후 이벤트를 예약 할 때는 오프셋이 변경되는 것이 일반적이므로 UTC 대신 현지 시간을 사용하는 것이 좋습니다. 답변블로그 게시물을 참조하십시오 .
  • 생일 및 기념일과 같은 전체 날짜를 저장하는 경우 UTC 또는 다른 시간대로 변환하지 마십시오.
    • 가능하면 시간을 포함하지 않는 날짜 전용 데이터 유형으로 저장하십시오.
    • 이러한 유형을 사용할 수없는 경우 값을 해석 할 때 항상 시간을 무시하십시오. 시간이 무시된다고 확신 할 수없는 경우, 그 날의보다 안전한 대표 시간으로 00:00 자정이 아닌 12:00 정오를 선택하십시오.
  • 표준 시간대 오프셋은 항상 정수 시간이 아닙니다 (예 : 인도 표준시는 UTC + 05 : 30이고 네팔은 UTC + 05 : 45를 사용합니다).
  • Java를 사용 하는 경우 Java 8 이상에 java.time 을 사용 하십시오 .
  • .NET을 사용하는 경우 Noda Time 사용을 고려하십시오 .
  • Noda Time없이 .NET을 사용하는 경우 .NET을 사용 DateTimeOffset하는 것이 더 나은 선택 인 경우가 많습니다 DateTime.
  • Perl을 사용하는 경우 DateTime을 사용하십시오 .
  • Python을 사용하는 경우 pytz 또는 dateutil을 사용 하십시오 .
  • JavaScript를 사용하는 경우 moment.jsmoment-timezone 확장명 과 함께 사용 하십시오 .
  • PHP> 5.2를 사용하는 DateTime경우 및 DateTimeZone클래스에서 제공하는 기본 시간대 변환을 사용하십시오 . 사용시주의하십시오 DateTimeZone::listAbbreviations()대답을 참조 . 최신 Olson 데이터를 사용하여 PHP를 유지하려면 timezonedb PECL 패키지를 정기적으로 설치 하십시오 . 답변을 참조하십시오 .
  • C ++를 사용하는 경우 IANA 시간대 데이터베이스를 올바르게 구현하는 라이브러리를 사용해야 합니다 . 여기에는 cctz , ICUHoward Hinnant의 “tz”라이브러리가 포함 됩니다.
    • 시간대 변환에 Boost 를 사용하지 마십시오 . API 는 표준 IANA (일명 “zoneinfo”) 식별자를 지원한다고 주장 하지만 각 영역의 풍부한 변경 기록을 고려하지 않고 POSIX 스타일 데이터에 매핑합니다 . 또한 파일이 유지 관리에서 제외되었습니다.
  • 녹을 사용하는 경우 chrono를 사용하십시오 .
  • 대부분의 비즈니스 규칙은 UTC 또는 GMT가 아닌 시민 시간을 사용합니다. 따라서 응용 프로그램 논리를 적용하기 전에 UTC 타임 스탬프를 현지 시간대로 변환해야합니다.
  • 시간대 및 오프셋은 고정되어 있지 않으며 변경 될 수 있습니다. 예를 들어, 역사적으로 미국과 영국은 같은 날짜를 ‘봄 앞으로’와 ‘뒤로’로 사용했습니다. 그러나 2007 년 미국은 시계가 바뀌는 날짜를 변경했습니다. 이것은 이제 48 주 동안 런던 시간과 뉴욕 시간의 차이가 5 시간이고 4 주 동안 (봄에 3, 가을에 1) 4 시간임을 의미합니다. 여러 영역을 포함하는 계산에서 이와 같은 항목을 알고 있어야합니다.
  • 정확한 검색을 위해 저장해야하는 요소 (타임 스탬프, 시간대 오프셋 및 시간대 이름)의 시간 유형 (실제 이벤트 시간, 브로드 캐스트 시간, 상대 시간, 기록 시간, 반복 시간)을 고려하십시오. 이 답변 .
  • OS와 데이터베이스 및 응용 프로그램 tzdata 파일을 자신과 다른 국가간에 동기화 상태로 유지하십시오.
  • 서버에서 하드웨어 시계 및 OS 시계를 현지 시간대가 아닌 UTC로 설정하십시오.
  • 이전 글 머리 기호에 관계없이 웹 사이트를 포함한 서버 측 코드 는 서버의 현지 시간대가 특별히 예상 되지 않아야합니다 . 답변을 참조하십시오 .
  • 구성 파일 설정 또는 기본값을 통하지 않고 애플리케이션 코드에서 사례별로 시간대를 사용하는 것이 좋습니다.
  • 모든 서버에서 NTP 서비스를 사용하십시오 .
  • FAT32를 사용하는 경우 타임 스탬프는 UTC가 아닌 현지 시간으로 저장됩니다.
  • 되풀이되는 이벤트 (예 : 주간 TV 프로그램)를 처리 할 때는 시간이 DST에 따라 달라지고 시간대에 따라 다릅니다.
  • 항상 날짜-시간 값을 하한값, 상한값 ( >=, <) 으로 쿼리하십시오 .

하지 마십시오 :

  • America/New_York“시간대 오프셋”과 같은 “시간대”와 혼동하지 마십시오 -05:00. 그것들은 서로 다른 두 가지입니다. 시간대 태그 위키를 참조하십시오 .
  • DateECMAScript 5.1 이하에는 일광 절약 시간을 잘못 사용할 수 있는 디자인 결함 이 있으므로 구식 웹 브라우저에서 날짜 및 시간 계산을 수행하기 위해 JavaScript 객체를 사용하지 마십시오 . (ECMAScript 6/2015에서 수정되었습니다).
  • 클라이언트의 시계를 절대 믿지 마십시오. 잘못되었을 수 있습니다.
  • 사람들에게 “항상 어디에서나 UTC를 사용하십시오”라고 말하지 마십시오. 이 광범위한 조언은이 문서의 앞부분에서 설명한 몇 가지 유효한 시나리오에 대한 근거입니다. 대신 작업중인 데이터에 적절한 시간 참조를 사용하십시오. ( 타임 스탬프는 UTC를 사용할 수 있지만 미래의 시간 스케줄링과 날짜 전용 값은 안된다.)

테스트 :

  • 테스트 할 때, 반드시 서부, 동부, 북부와 국가 시험 만든다 남부 진행중인 두 DST와, (세계의 각 분기에 그렇게 4 개 지역을 사실) 반구를하지 (8 제공)을 수행하는 국가 DST를 사용하지 마십시오 (또 다른 4 개는 모든 지역을 커버하므로 총 12 개가됩니다).
  • DST의 전환을 테스트합니다. 즉, 현재 여름 시간 인 경우 겨울에서 시간 값을 선택하십시오.
  • DST를 사용하여 UTC + 12 인 시간대와 같은 경계 사례를 테스트 하여 여름 에는 현지 시간을 UTC + 13으로, 겨울에는 UTC + 13으로 설정합니다.
  • 모든 타사 라이브러리 및 응용 프로그램을 테스트하고 표준 시간대 데이터를 올바르게 처리하는지 확인하십시오.
  • 적어도 30 분의 시간대를 테스트하십시오.

참고:

다른:

  • DST 인 가증을 종식시키기 위해 담당자를 로비하십시오. 우리는 항상 희망 할 수 있습니다 …
  • 지구 표준시 로비

답변

위의 답변에 무엇을 추가 할 수 있는지 잘 모르겠지만 여기 몇 가지 사항이 있습니다.

시간의 종류

고려해야 할 네 가지 다른 시간이 있습니다.

  1. 이벤트 시간 : 예를 들어 국제 스포츠 이벤트가 발생하는 시간 또는 대관식 / 사망 등 이는 시청자가 아닌 이벤트 시간대에 따라 다릅니다.
  2. 텔레비전 시간 : 예를 들어 특정 TV 쇼는 전 세계 현지 시간으로 오후 9시에 방송됩니다. 웹 사이트에 결과 (아메리칸 아이돌 등)를 게시 할 때 중요
  3. 상대 시간 : 예 :이 질문은 21 시간 안에 공개 현상금이 마감됩니다. 이것은 표시하기 쉽다
  4. 되풀이 시간 : 예 : DST가 변경되는 경우에도 매주 월요일 오후 9시에 TV 쇼가 열립니다.

역사 / 대체 시간도 있습니다. 그들은 표준 시간으로 다시 매핑되지 않을 수 있기 때문에 성가시다. 예 : 줄리안 날짜, 토성의 음력 달력에 따른 날짜, 클링 온 달력.

시작 / 종료 타임 스탬프를 UTC로 저장하면 효과적입니다. 1의 경우, 이벤트 시간대 이름 + 오프셋이 이벤트와 함께 저장되어 있어야합니다. 2의 경우, 각 지역에 저장된 현지 시간 식별자와 모든 뷰어에 대해 저장된 현지 시간대 이름 + 오프셋이 필요합니다 (크런치 상태 인 경우 IP에서이를 추출 할 수 있음). 3의 경우 UTC 초로 저장하고 시간대가 필요하지 않습니다. 4는 글로벌 이벤트인지 로컬 이벤트인지에 따라 1 또는 2의 특수한 경우이지만, 타임 스탬프 에서 작성된 이벤트를 저장 해야이 이벤트 작성 전후에 시간대 정의가 변경되었는지 알 수 있습니다. 과거 데이터를 표시해야하는 경우 필요합니다.

저장 시간

  • 항상 UTC로 시간을 저장
  • 디스플레이시 현지 시간으로 변환 (사용자가 데이터를보고 정의한 현지 시간)
  • 시간대를 저장할 때 이름, 타임 스탬프 및 오프셋이 필요합니다. 정부가 시간대 (예 : 미국 정부가 DST 날짜를 변경 함)의 의미를 때때로 변경하고 애플리케이션이 정상적으로 처리해야하기 때문에이 작업이 필요합니다. 변경되었습니다.

오프셋과 이름

위의 예는 다음과 같습니다.

축구 월드컵 결승전은 2010 년 7 월 11 일 19:00 UTC에 남아프리카 (UTC + 2–SAST)에서 진행되었습니다.

2010 WCS 결승전은 남아프리카 시간대 정의가 변경 되더라도 자리했다 때이 정보를 사용하여, 우리는 역사적으로 정확한 시간을 확인할 수 있습니다 그리고 그들은 데이터베이스를 쿼리 할 때 시간에 자신의 로컬 시간대에 시청자들에게 그를 표시 할 수 있습니다.

시스템 시간

또한 OS, 데이터베이스 및 응용 프로그램 tzdata 파일을 서로 및 전세계와 동기화 된 상태로 유지하고 업그레이드 할 때 광범위하게 테스트해야합니다. 귀하가 의존하는 타사 앱이 TZ 변경을 올바르게 처리하지 않았다는 이야기는 들어 본 적이 없습니다.

하드웨어 시계가 UTC로 설정되어 있는지 확인하고 전세계에서 서버를 실행중인 경우 해당 OS가 UTC를 사용하도록 구성되어 있는지 확인하십시오. 이는 여러 시간대의 서버에서 시간 단위로 회전 된 아파치 로그 파일을 복사해야 할 때 분명해집니다. 파일 이름을 기준으로 파일을 정렬하면 모든 파일의 이름이 같은 시간대 인 경우에만 작동합니다. 또한 한 상자에서 다른 상자로 ssh하고 타임 스탬프를 비교해야 할 때 머리에 날짜 계산을 할 필요가 없음을 의미합니다.

또한 모든 상자에서 ntpd를 실행하십시오.

고객

클라이언트 컴퓨터에서 얻은 타임 스탬프를 유효하다고 절대 신뢰하지 마십시오. 예를 들어, Date : HTTP 헤더 또는 javascript Date.getTime()호출입니다. 이것은 불투명 한 식별자로 사용되거나 동일한 클라이언트에서 단일 세션 동안 날짜 계산을 수행 할 때 적합하지만 서버에있는 값과 이러한 값을 상호 참조하지 마십시오. 클라이언트가 NTP를 실행하지 않으며 BIOS 시계 용 배터리가 작동하지 않을 수도 있습니다.

하찮은 일

마지막으로 정부는 때때로 매우 이상한 일을합니다.

네덜란드의 표준 시간은 법에 의해 1909-05-01에서 1937-06-30까지 UTC보다 정확히 19 분 32.13 초 빠릅니다. 이 시간대는 HH : MM 형식을 사용하여 정확하게 표현할 수 없습니다.

좋아, 나는 끝났다고 생각한다.


답변

이것은 중요하고 놀랍도록 어려운 문제입니다. 진실은 시간을 유지하기 위해 완전히 만족하는 표준이 없다는 것입니다. 예를 들어, SQL 표준과 ISO 형식 (ISO 8601)으로는 충분하지 않습니다.

개념적 관점에서 하나는 일반적으로 두 가지 유형의 시간 날짜 데이터를 처리하며 ” 물리적 시간 “과 ” 민간 시간 “이라는 두 가지 유형의 데이터를 구분하는 것이 편리합니다 (위의 표준은 그렇지 않습니다) .

“물리적”시간 순간은 물리가 다루는 연속적인 보편적 타임 라인의 한 지점입니다 (물론 상대성을 무시 함). 이 개념은 예를 들어 UTC로 적절히 코딩되어 지속될 수 있습니다 (윤초를 무시할 수있는 경우).

“시민”시간은 민사 규범을 따르는 날짜 시간 사양입니다. 여기서 시간은 일련의 날짜 시간 필드 (Y, M, D, H, MM, S, FS)와 TZ (시간대 사양)로 완전히 지정됩니다. (실제로는 “달력”이지만 토론을 그레고리력으로 제한한다고 가정합니다). 시간대와 달력은 원칙적으로 하나의 표현에서 다른 표현으로의 매핑을 허용합니다. 그러나 민간 및 물리적 시간 순간은 근본적으로 다른 유형의 크기이며, 개념적으로 분리하여 다르게 취급해야합니다 (유사한 배열 : 바이트 배열 및 문자열).

이러한 유형의 사건을 서로 바꿔서 말할 수 있고, 시민 시대에는 정치적 변화가 있기 때문에 문제는 혼란 스럽습니다. 문제 (및 이러한 개념을 구별 할 필요성)는 미래의 이벤트에 대해 더욱 분명해집니다. 예 (내 토론 에서 가져온 입니다.

John은 달력에서 datetime 2019-Jul-27, 10:30:00, TZ =의 일부 이벤트에 대한 알림을 기록합니다
Chile/Santiago(GMT-4 오프셋이 있으므로 UTC에 해당 2019-Jul-27 14:30:00). 그러나 앞으로 언젠가는 TZ 오프셋을 GMT-5로 변경하기로 결정했습니다.

이제, 하루가 오면 … 알림이 트리거되어야합니까?

A) 2019-Jul-27 10:30:00 Chile/Santiago = UTC time 2019-Jul-27 15:30:00?

또는

B) 2019-Jul-27 9:30:00 Chile/Santiago = UTC time 2019-Jul-27 14:30:00?

요한이 달력에 “Please ring me at 2019-Jul-27, 10:30:00
TZ=Chile/Santiago
” 이라고 말했을 때 개념적으로 무엇을 의미하는지 알지 않는 한 정답은 없습니다 .

그는 “시민 날짜-시간”을 의미 했습니까 ( “내 도시의 시계가 10:30을 말할 때”)? 이 경우 A)가 정답입니다.

또는 “우주 일식이 일어날 때”라는 우주의 연속 선에있는 “물리적 순간”을 의미 했습니까? 이 경우 B)가 정답입니다.

몇몇 날짜 / 시간 API는 이러한 구별을 갖습니다. 그중 에서 다음 (제 3!) Java DateTime API (JSR 310)의 기초 인 Jodatime 이 있습니다.


답변

관심사를 명확하게 구분하여 사용자와 상호 작용하는 계층을 정확히 파악하고 표준 표현 (UTC)의 날짜 / 시간을 변경해야합니다. 비 UTC 날짜-시간은 프리젠 테이션 (사용자 현지 시간대를 따릅니다), UTC 시간은 모델입니다 (백엔드 및 중간 계층에 대해 고유함).

또한 실제 잠재 고객이 무엇인지, 무엇을 제공하지 않아도되며 어디에 선을 그을지 결정합니다 . 실제로 중요한 고객이없는 경우 이국적인 달력을 만지지 말고 해당 지역에 대한 별도의 사용자 대면 서버를 고려하십시오.

사용자의 위치를 ​​확보하고 유지할 수있는 경우 체계적인 날짜-시간 변환 (예 : .NET 문화 또는 SQL 테이블) 위치를 사용하되 최종 사용자가 날짜-시간이 사용자에게 중요한 경우 재정의를 선택할 수있는 방법을 제공하십시오.

기록 감사 의무가있는 경우 (AZ의 Jo가 9 년 전에 2 년 전에 청구서를 언제 지불했는지 정확히 알려주는 것과 같이) UTC와 현지 시간 을 모두 기록하여 기록하십시오 (변환 표는 시간이 지남 에 따라 변경됨).

파일, 웹 서비스 등과 같이 대량으로 제공되는 데이터의 시간 참조 표준 시간대를 정의하십시오 . East Coast 회사에 CA에 데이터 센터가 있다고 가정하면 데이터를 표준으로 사용하는 것이 아니라 다른 것으로 가정하는 것이 무엇인지 알아야합니다.

날짜-시간의 텍스트 표현에 포함 된 시간대 오프셋을 신뢰하지 말고 구문 분석 및 따르지 않습니다. 대신 항상 표준 시간대 및 / 또는 참조 영역을 명시 적으로 정의해야 합니다. PST 오프셋으로 시간을 쉽게 수신 할 수 있지만 클라이언트의 참조 시간이므로 레코드가 PST 인 서버에서 방금 내보내 졌기 때문에 실제로는 EST입니다.


답변

Olson tz 데이터베이스 에 대해서는 ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/ 에서 확인할 수 있습니다 . 전 세계 여러 국가에서 겨울과 여름 (표준 및 일광 절약 시간) 시간 사이를 전환해야하는 시점과 마지막 순간의 변경 사항을 처리하기 위해 매년 여러 차례 업데이트됩니다. 2009 년 마지막 릴리스는 2009 년입니다. 2010 년에는 2010 년이었습니다. 2011 년에는 2011n이었습니다. 2012 년 5 월 말에 릴리스는 2012c입니다. 두 개의 별도 아카이브 (tzcode20xxy.tar.gz 및 tzdata20xxy.tar.gz)에는 데이터 및 실제 시간대 데이터 자체를 관리하는 코드 세트가 있습니다. 코드와 데이터는 모두 공개 도메인에 있습니다.

이것은 America / Los_Angeles와 같은 표준 시간대 이름 (미국 / 태평양과 같은 동의어)입니다.

다른 영역을 추적해야하는 경우 Olson 데이터베이스가 필요합니다. 다른 사람들이 조언했듯이 데이터를 생성 한 시간대에 대한 레코드와 함께 고정 형식 (UTC는 일반적으로 선택된 형식)으로 데이터를 저장하려고합니다. 시간에서 UTC와의 오프셋과 시간대 이름을 구별 할 수 있습니다. 나중에 차이를 만들 수 있습니다. 또한 현재 2010-03-28T23 : 47 : 00-07 : 00 (미국 / 태평양) 인 경우 2010-11-15T12 : 30 값을 해석하는 데 도움이되거나 도움이되지 않을 수 있습니다. 이는 PST ( 태평양 표준시)가 아닌 PDT (태평양 표준시)입니다.

표준 C 라이브러리 인터페이스는 이런 종류의 것들에 크게 도움이되지 않습니다.


Olson 데이터는 AD Olson이 곧 퇴직 ​​할 예정이고 일부는 저작권 침해에 대한 유지 관리인에 대해 (현재 기각 된) 소송이 있었기 때문에 이동했습니다. 시간대 데이터베이스는 이제 IANA ( Internet Assigned Numbers Authority) 의 후원하에 관리 되며, 첫 페이지에는 ‘Time Zone Database’링크가 있습니다. 토론 메일 링리스트는 이제 tz@iana.org; 공지 사항 목록은 tz-announce@iana.org입니다.


답변

일반적으로 저장된 타임 스탬프에 로컬 시간 오프셋 (DST 오프셋 포함)포함시킵니다 . 나중에 타임 스탬프를 원래 시간대 (및 DST 설정)로 표시하려는 경우 UTC만으로는 충분하지 않습니다.

오프셋은 항상 정수 시간이 아닙니다 (예 : 인도 표준시는 UTC + 05 : 30).

예를 들어, 적합한 형식은 튜플 (유닉스 시간, 분 단위 오프셋) 또는 ISO 8601 입니다.


답변

“컴퓨터 시간”과 “사람 시간”의 경계를 넘어가는 것은 악몽입니다. 시간대와 일광 절약 시간을 규정하는 규칙에 대한 표준이 없다는 것이 주요 문제입니다. 국가는 언제든지 시간대 및 DST 규칙을 자유롭게 변경할 수 있으며 변경합니다.

브라질, 이스라엘과 같은 일부 국가에서는 매년 일광 절약 시간을 정할시기를 결정하므로 DST가 언제 적용되는지 미리 알 수 없습니다. 다른 사람들은 DST가 시행되는 시점에 대해 정해진 규칙을 가지고 있습니다. 다른 국가에서는 DST를 모두 사용하지 않습니다.

시간대는 GMT와의 전체 시간 차이 일 필요는 없습니다. 네팔은 +5.45입니다. +13 시간대도 있습니다. 이는 다음을 의미합니다.

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT
TUE 00:00 in Tonga (+13)

모두 같은 시간이지만 3 일이 지났습니다!

시간대의 약어에 대한 명확한 표준과 DST에있을 때 시간대가 어떻게 변경되어 다음과 같은 결과가 나타납니다.

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

가장 좋은 조언은 가능한 한 현지 시간을 피하고 UTC를 고수하는 것입니다. 마지막 순간에만 현지 시간으로 변환하십시오.

테스트 할 때는 DST가 진행되고 있고 DST를 사용하지 않는 국가 (총 6 개)와 함께 서반구와 동부 반구의 국가를 테스트해야합니다.