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

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

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

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

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

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

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

프로그래밍, 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 을 사용 하십시오 .
  • 그 java.time 기능의 대부분은 ThreeTen-Backport 라이브러리 에서 Java 6 & 7로 백 포트됩니다 .
  • ThreeTenABP 라이브러리의 초기 Android (<26)에 더 적합 합니다.
  • 이 프로젝트는 공식적으로 현재 유지 보수 모드 인 훌륭한 Joda-Time을 대체 합니다 . Joda-Time, ThreeTen-Backport, ThreeTen-Extra , java.time 클래스 및 JSR 310 은 같은 사람인 Stephen Colebourne 이 주도합니다 .
• .NET을 사용하는 경우 Noda Time 사용을 고려하십시오 .
• Noda Time없이 .NET을 사용하는 경우 .NET을 사용 DateTimeOffset하는 것이 더 나은 선택 인 경우가 많습니다 DateTime.
• Perl을 사용하는 경우 DateTime을 사용하십시오 .
• Python을 사용하는 경우 pytz 또는 dateutil을 사용 하십시오 .
• JavaScript를 사용하는 경우 moment.js 를 moment-timezone 확장명 과 함께 사용 하십시오 .
• PHP> 5.2를 사용하는 DateTime경우 및 DateTimeZone클래스에서 제공하는 기본 시간대 변환을 사용하십시오 . 사용시주의하십시오 DateTimeZone::listAbbreviations()- 대답을 참조 . 최신 Olson 데이터를 사용하여 PHP를 유지하려면 timezonedb PECL 패키지를 정기적으로 설치 하십시오 . 답변을 참조하십시오 .
• C ++를 사용하는 경우 IANA 시간대 데이터베이스를 올바르게 구현하는 라이브러리를 사용해야 합니다 . 여기에는 cctz , ICU 및 Howard 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 분의 시간대를 테스트하십시오.

참고:

• timezoneStack Overflow 의 자세한 태그 위키 페이지
• Olson 데이터베이스, 일명 Tz_database
• Olson 데이터베이스 유지 관리를위한 IETF 초안 절차
• 시간대 및 DST 소스
• ISO 형식 (ISO 8601)
• 유니 코드 컨소시엄에서 Olson 데이터베이스와 Windows 표준 시간대 ID 간 매핑
• Wikipedia의 시간대 페이지
• StackOverflow 질문 태그 dst
• StackOverflow 질문 태그 timezone
• DST 다루기-Microsoft DateTime 모범 사례
• Wikipedia의 네트워크 시간 프로토콜

다른:

• 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 개)와 함께 서반구와 동부 반구의 국가를 테스트해야합니다.

PHP의 경우 :

PHP> 5.2의 DateTimeZone 클래스는 이미 다른 사람들이 언급 한 Olson DB를 기반으로하므로 DB가 아닌 PHP에서 시간대 변환을 수행하는 경우 이해하기 어려운 Olson 파일에 대한 작업이 면제됩니다.

그러나 PHP는 Olson DB만큼 자주 업데이트되지 않으므로 PHP 표준 시간대 변환 만 사용하면 오래된 DST 정보가 남아 데이터의 정확성에 영향을 줄 수 있습니다. 이러한 상황은 자주 발생하지는 않지만 전 세계에 대규모 사용자 가 있는 경우 발생할 수 있습니다.

위의 문제를 해결하려면 timezonedb pecl package를 사용하십시오 . 그 기능은 PHP의 시간대 데이터를 업데이트하는 것입니다. 업데이트 될 때마다이 패키지를 설치하십시오. (이 패키지의 업데이트가 Olson 업데이트를 정확히 따르는 지 확실하지 않지만 Olson 업데이트의 빈도와 가장 가까운 빈도로 업데이트되는 것 같습니다.)

당신의 디자인이 그것을 수용 할 수 있다면, 현지 시간 변환을 함께 피하십시오!

나는 이것이 미친 것처럼 들릴 수도 있지만 UX에 대해 생각합니다. 사용자는 절대 날짜 (2010.09.17, 9 월 17 일 금요일)보다 가까운 상대 날짜 (오늘, 어제, 다음 월요일)를 한 눈에 빠르게 처리합니다. 그리고 당신이 그것에 대해 더 많이 생각할 때, 시간대 (및 DST)의 정확성은 날짜가 가까울수록 더 중요합니다 now(). 따라서 날짜 / 날짜 시간을 +/- 1 또는 2 주 동안 상대 형식으로 표현할 수 있다면 날짜는 UTC 일 수 있으며 사용자의 95 %에게 너무 중요하지 않습니다.

이렇게하면 모든 날짜를 UTC로 저장하고 상대 비교를 UTC로 수행 할 수 있으며 상대 날짜 임계 값을 벗어난 사용자 UTC 날짜를 간단히 표시 할 수 있습니다.

이것은 또한 사용자 입력에도 적용될 수 있습니다 (그러나 일반적으로 더 제한된 방식으로). {어제, 오늘, 내일, 다음 월요일, 다음 목요일} 만있는 드롭 다운 메뉴에서 선택하는 것이 날짜 선택 도구보다 훨씬 간단하고 쉽습니다. 날짜 선택기는 양식 작성의 가장 고통스러운 구성 요소 중 일부입니다. 물론 이것은 모든 경우에 적용되지는 않지만 매우 강력하게 만들기 위해서는 약간의 영리한 디자인 만 필요하다는 것을 알 수 있습니다.

시도하지는 않았지만 시간대 조정에 대한 접근 방식은 다음과 같습니다.

1. 모든 것을 UTC로 저장하십시오.

2. TZOffsetsRegionClassId, StartDateTime 및 OffsetMinutes (int, 분)의 세 열이 있는 테이블 을 만듭니다 .

표에서 날짜 및 시간의 목록을 저장할 때 얼마나하여 로컬 시간이 변경합니다. 표의 지역 수와 날짜 수는 지원해야하는 날짜 및 지역의 범위에 따라 다릅니다. 날짜가 미래를 어느 정도 제한적으로 포함해야한다고해도 이것을 "역사적"날짜 인 것처럼 생각하십시오.

UTC 시간의 현지 시간을 계산해야하는 경우 다음을 수행하십시오.

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

앱에서이 테이블을 캐시하고 LINQ 또는 이와 유사한 방법을 사용하여 데이터베이스에 도달하지 않고 쿼리를 수행 할 수 있습니다.

이 데이터는 공개 도메인 tz 데이터베이스 에서 추출 할 수 있습니다 .

이 방법의 장점과 각주 :

1. 코드에 규칙이 적용되지 않으므로 새로운 지역 또는 날짜 범위에 대한 오프셋을 쉽게 조정할 수 있습니다.
2. 모든 날짜 또는 지역 범위를 지원할 필요는 없으며 필요에 따라 추가 할 수 있습니다.
3. 지역은 지정 학적 경계에 직접 대응할 필요가없고 행의 중복을 피하기 위해 (예를 들어 미국의 대부분의 주에서는 DST를 동일한 방식으로 처리) 다른 테이블에서보다 전통적인 주, 국가 등
4. 지난 몇 년 동안 DST의 시작 날짜와 종료 날짜가 변경된 미국과 같은 상황에서는이 문제를 다루기가 매우 쉽습니다.
5. StartDateTime 필드도 시간을 저장할 수 있으므로 오전 2:00 표준 변경 시간을 쉽게 처리 할 수 ​​있습니다.
6. 전 세계 어디에서나 1 시간 DST를 사용하는 것은 아닙니다. 이것은 그러한 경우를 쉽게 처리합니다.
7. 데이터 테이블은 크로스 플랫폼이며 거의 모든 데이터베이스 플랫폼 또는 프로그래밍 언어를 사용하는 개발자가 사용할 수있는 별도의 오픈 소스 프로젝트 일 수 있습니다.
8. 시간대와 관련이없는 오프셋에 사용할 수 있습니다. 예를 들어, 지구의 회전, 그레고리력과의 기록 조정 등을 위해 때때로 발생하는 1 초 조정.
9. 데이터베이스 테이블에 있기 때문에 표준 보고서 쿼리 등은 비즈니스 논리 코드를 통하지 않고 데이터를 활용할 수 있습니다.
10. 이는 원하는 경우 시간대 오프셋도 처리하며, 다른 시간대에 지역이 지정된 특별한 과거 사례를 설명 할 수도 있습니다. 최소한의 시작 날짜로 각 지역에 시간대 오프셋을 할당하는 초기 날짜 만 있으면됩니다. 각 시간대마다 하나 이상의 지역을 만들어야하지만 다음과 같은 흥미로운 질문을 할 수 있습니다. "1989 년 2 월 2 일 오전 5시에 애리조나 유마와 워싱턴 시애틀의 현지 시간 차이는 무엇입니까?" (단 하나의 SUM ()을 다른 것에서 빼십시오).

이제,이 방법의 유일한 단점 이나 다른 변환 즉 에서 클럭 오프셋 음이있는 DST 변경 이후 현지 시간 GMT로는 완벽하지 반복 주어진 현지 시간. 그 중 하나를 다루는 쉬운 방법은 없습니다. 현지 시간을 저장하는 것이 처음에는 나쁜 소식입니다.

최근 웹 애플리케이션에서 Ajax 포스트 백에서 서버 측 코드로 돌아 오는 날짜 시간이 제공된 날짜 시간과 다른 문제가 발생했습니다.

JavaScript는 시간대와 일광 절약 시간을 조정하고 일부 브라우저에서는 일광 절약 시간을 적용하는 시간을 계산하기 때문에 클라이언트에 문자열로 다시 게시 할 날짜를 만든 클라이언트의 JavaScript 코드와 관련이있을 가능성이 큽니다. 다른 사람들과는 다른 것 같았습니다.

결국 나는 클라이언트에서 날짜 및 시간 계산을 완전히 제거하고 정수 키로 서버에 다시 게시 한 다음 서버에서 날짜 시간으로 변환하여 일관된 변환을 허용했습니다.

이것에 대한 나의 학습 : 절대적으로해야하지 않는 한 웹 응용 프로그램에서 JavaScript 날짜 및 시간 계산을 사용하지 마십시오.

나는“시프트 계획 시스템 (예 : 공장 노동자)”과“가스 의존 관리 시스템”이라는 두 가지 유형의 시스템에서이 문제에 부딪쳤다.

23 시간과 25 시간의 긴 하루는 극복하기 힘든 고통이므로 7 시간이나 9 시간이 걸리는 8 시간의 교대 근무도 있습니다. 문제는 각 고객 또는 고객 부서가 이러한 특수한 경우에 수행 한 작업에 대해 서로 다른 규칙을 작성한다는 것입니다 (종종 문서화하지 않음).

고객이 "기성품"소프트웨어에 대한 비용을 지불하기 전까지는 고객에게 어떤 질문을하지 않는 것이 가장 좋습니다. 소프트웨어를 구입할 때 이러한 유형의 문제를 미리 생각하는 고객을 찾는 것은 매우 드 rare니다.

나는 모든 경우에 UTC로 시간을 기록하고 날짜 / 시간을 저장하기 전에 현지 시간으로 변환해야한다고 생각합니다. 그러나 일광 절약 시간 및 시간대를 사용하면 주어진 시간이 어느 정도인지 알 수 없습니다.

웹의 경우 규칙은 그렇게 복잡하지 않습니다 ...

• 서버 측, UTC 사용
• 고객 측, Olson 사용
  • 이유 : UTC 오프셋은 일광 절약 시간 제로 안전하지 않습니다 (예 : 뉴욕은 연중 EST (UTC-5 시간), EDT (UTC-4 시간) 나머지 기간).
  • 클라이언트 측 시간대 결정의 경우 두 가지 옵션이 있습니다.
    • 1) 사용자가 영역을 설정하도록합니다 (보다 안전)
      • 리소스 : 웹 지원 Olson tz HTML 드롭 다운 및 JSON
    • 2) 자동 감지 영역
      • 리소스 : jsTimezoneDetect

나머지는 서버 측 날짜 시간 라이브러리를 사용하는 UTC / 로컬 변환입니다. 잘가요 ...

웹 사이트 및 기타 백엔드 서비스를 포함 하여 서버 에서 실행되는 응용 프로그램의 경우 응용 프로그램에서 서버의 시간대 설정을 무시해야합니다.

일반적인 조언은 서버의 시간대를 UTC로 설정하는 것입니다. 이것은 실제로 모범 사례이지만 다른 모범 사례를 따르지 않는 응용 프로그램에 대한 반창고가 있습니다. 예를 들어, 서비스는 UTC 기반 타임 스탬프 대신 로컬 타임 스탬프가있는 파일을 로그 파일에 작성하여 일광 절약 시간 대체 전환 중에 모호성을 생성 할 수 있습니다. 서버의 시간대를 UTC로 설정하면 해당 애플리케이션 이 수정 됩니다. 그러나 실제 수정은 응용 프로그램이 UTC를 사용하여 시작하는 것입니다.

웹 사이트를 포함한 서버 측 코드 는 서버의 현지 시간대가 무엇인지 예상 해서는 안됩니다 .

일부 언어에서는 현지 시간대가 응용 프로그램 코드에 쉽게 영향을 줄 수 있습니다. 예를 들어, DateTime.ToUniversalTime.NET의 방법은 변환됩니다 에서 UTC 로컬 시간대 및 DateTime.Now속성은 로컬 타임 존의 현재 시간을 반환합니다. 또한 DateJavaScript 의 생성자는 컴퓨터의 현지 시간대를 사용합니다. 이와 같은 다른 많은 예가 있습니다. 컴퓨터의 현지 시간대 설정을 사용하는 코드를 피하면서 방어 프로그래밍을 연습하는 것이 중요합니다.

데스크톱 응용 프로그램, 모바일 응용 프로그램 및 클라이언트 쪽 JavaScript와 같은 클라이언트 쪽 코드에 현지 시간대를 사용하여 예약하십시오.

서버를 UTC로 설정하고 모든 서버가 ntp 또는 이와 동등한 것으로 구성되어 있는지 확인하십시오.

UTC는 일광 절약 시간제 문제를 피하고 동기화되지 않은 서버는 예기치 않은 결과를 초래하여 진단하는 데 시간이 걸립니다.

FAT32 파일 시스템에 저장된 타임 스탬프를 다룰 때주의하십시오. 항상 로컬 시간 좌표 (DST 포함 -msdn 기사 참조 )로 유지됩니다. 저것에 타 버렸습니다.

다른 하나는, 서버에 최신 일광 절약 패치가 적용되어 있는지 확인하십시오.

작년에 UTC 기반 시스템을 사용하고 있었지만 북미 사용자의 경우 3 주 동안 한 시간 씩 꾸준히 나가는 상황이있었습니다.

결국 서버였습니다. 최신 패치 만 적용하면됩니다 ( Windows Server 2003 ).

PHP의 DateTimeZone::listAbbreviations()출력

이 PHP 메소드는 '주요'시간대 (CEST와 같은)를 포함하는 연관 배열을 리턴하는데,이 시간대에는 자체적으로보다 구체적인 '지리적'시간대 (유럽 / 암스테르담)가 포함되어 있습니다.

이러한 시간대와 해당 오프셋 / DST 정보를 사용하는 경우 다음을 인식하는 것이 매우 중요합니다.

그것은 것 같아 모두 다른 오프셋 / DST 구성에 포함 된 각 시간대의 (역사적 구성 포함)!

예를 들어, 유럽 / 암스테르담은이 기능의 출력에서 ​​6 번 발견 될 수 있습니다. 두 번의 발생 (오프셋 1172/4772)은 1937 년까지 사용 된 암스테르담 시간입니다. 2 (1200/4800)는 1937 년에서 1940 년 사이에 사용 된 시간입니다. 1940 년 이래 2 (3600/4800)가 사용되었습니다

따라서이 기능에서 반환 된 오프셋 / DST 정보 를 현재 올바른 / 사용중인 것으로 신뢰할 수 없습니다 !

특정 시간대의 현재 오프셋 / DST를 알고 싶다면 다음과 같이해야합니다.

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

DST를 활성 상태로 실행중인 데이터베이스 시스템을 유지 관리하는 경우 가을에 전환하는 동안 데이터베이스 시스템을 종료해야하는지주의 깊게 확인하십시오. Mandy DBS (또는 다른 시스템도)는 같은 시간 (현지 시간)을 두 번 통과하는 것을 좋아하지 않습니다. 이는 정확히 시계를 가을에 되돌릴 때 발생합니다. SAP는 (IMHO 정말 깔끔한) 해결 방법 으로이 문제를 해결했습니다. 시계를 다시 돌리지 않고 내부 시계를 2 시간 동안 평소 속도의 절반으로 돌리십시오.

.NET 프레임 워크 를 사용하고 있습니까? 그렇다면 .NET 3.5에 추가 된 DateTimeOffset 유형 을 소개하겠습니다 .

이 구조는 인스턴스의 날짜와 시간과 UTC (Coordinated Universal Time) 의 차이를 지정 DateTime하는 오프셋 ( TimeSpan) 과 오프셋 ( )을 모두 보유합니다 DateTimeOffset.

• DateTimeOffset.Now정적 방법은 반환 DateTimeOffset 현재 (로컬) 시간으로 구성된 인스턴스 및 (운영 체제의 지역 정보에 정의 된대로) 오프셋 (offset) 지역을.

• DateTimeOffset.UtcNow정적 메서드는 반환합니다 DateTimeOffset(당신이 그리니치에있는 것처럼) UTC에서 현재 시간으로 구성된 인스턴스를.

다른 유용한 유형은 TimeZone 및 TimeZoneInfo 클래스입니다.

.NET 에서이 문제를 겪고있는 사람들 은 사용 중 DateTimeOffset및 / 또는 TimeZoneInfo가치가 있는지 확인하십시오.

IANA / Olson 표준 시간대 를 사용 하거나 필요에 따라 내장 유형이 충분하지 않은 경우 Noda Time을 확인하십시오 .

비즈니스 규칙은 항상 다른 시간에 적용되는 법이없는 한 시민 시간 에 적용되어야합니다 . 시민의 시간은 엉망이지만 사람들이 사용하는 것이 중요하므로 중요합니다.

내부적으로 타임 스탬프를 획기적인 시간 (초 단위)과 같은 형식으로 유지합니다. 시대는 중요하지 특히 (내가 선호하지 유닉스 시대를 )하지만 다른 것보다 쉽게 물건을한다. 척 윤초는 당신이 일을하지 않는 한 존재하지 않는 정말 그들 (예를 들어, 위성 추적)를 필요로한다. 타임 스탬프와 표시된 시간 간의 매핑은 DST 규칙을 적용해야하는 유일한 지점입니다 . 규칙은 자주 (전 세계적으로 1 년에 여러 번 정치인을 비난 함) 변경하기 때문에 매핑을 하드 코딩하지 않아야합니다. Olson의 TZ 데이터베이스 는 매우 중요합니다.

부정확하거나 적어도 혼란스러워 보이는 두 가지를 지적하고 싶었습니다.

일광 절약 시간의 영향을받지 않는 통합 표준에 따라 항상 시간을 유지하십시오. UTC가 가장 자주 언급되는 것처럼 보이지만 GMT와 UTC는 다른 사람들이 언급했습니다.

(거의) 모든 실제 컴퓨팅 목적으로 UTC는 실제로 GMT입니다. 초 단위의 타임 스탬프가 표시되지 않으면 GMT를 처리하여이 구분을 중복시킵니다.

타임 스탬프를 저장할 때 로컬 시간 오프셋을 그대로 (DST 오프셋 포함) 포함하십시오.

타임 스탬프는 항상 GMT로 표시되므로 오프셋이 없습니다.

내 경험은 다음과 같습니다.

(타사 라이브러리가 필요 없음)

• 서버 측에서는 사용자, 서버, 시간대 또는 DST의 위치에 관계없이 데이터베이스의 모든 날짜 / 시간 값이 단일 표준이되도록 UTC 형식으로 시간을 저장하십시오.
• UI 계층 또는 사용자에게 발송 된 이메일에서 사용자에 따라 시간을 표시해야합니다. 이를 위해서는 사용자의 현지 시간이 될 데이터베이스의 UTC 값에이 오프셋을 추가 할 수 있도록 사용자의 시간대 오프셋이 있어야합니다. 사용자가 가입 할 때 시간대 오프셋을 가져 오거나 웹 및 모바일 플랫폼에서 자동으로 감지 할 수 있습니다. 웹 사이트의 경우 JavaScript 함수 getTimezoneOffset () 메서드는 버전 1.0부터 표준이며 모든 브라우저와 호환됩니다. (참고 : http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )

Computerphile 채널의 YouTube 시간대에 대한 Tom Scott의 비디오 에는 주제에 대한 훌륭하고 재미있는 설명이 있습니다. 예를 들면 다음과 같습니다.

• 호주와 뉴질랜드와의 거래를 더 쉽게하기 위해 태평양의 섬인 Samoa가 시간대를 24 시간 앞당기 고 있습니다.
• 2 명의 인구가 다른 시간대를 따르는 West Bank
• 18 세기는 율리우스 력에서 그레고리력 (20 세기 러시아에서 일어난)으로 변경됩니다.

실제로 kernel32.dll은 SystemTimeToTzSpecificLocation을 내 보내지 않습니다. 그러나 SystemTimeToTzSpecificLocalTime 및 TzSpecificLocalTimeToSystemTime ...을 내 보냅니다.

같은 생성자에만 의존하지 마십시오

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

DST로 인해 특정 날짜 시간이 존재하지 않으면 예외가 발생할 수 있습니다. 대신, 그러한 날짜를 만드는 고유 한 방법을 만드십시오. 여기에서 DST로 인해 발생하는 예외를 포착하고 전환 오프셋으로 필요한 시간을 조정하십시오. 표준 시간대에 따라 DST는 다른 날짜와 다른 시간 (브라질의 자정에도)에 발생할 수 있습니다.

처리 시간이 설명 된 엄청난 혼란이며 결코 만족스럽지 않다는 것을 증명하는 한 가지 예입니다. 이 페이지의 여러 지점에서 윤초는 무시되었습니다.

몇 년 전에 Android 운영 체제는 GPS 위성을 사용하여 UTC 시간 참조를 얻었지만 GPS 위성이 윤초를 사용하지 않는다는 사실을 무시했습니다. Apple 전화 사용자와 Android 전화 사용자가 약 15 초 간격으로 카운트 다운을 수행 한 새해 전날에 혼란이 생길 ​​때까지 아무도 눈치 채지 못했습니다.

나는 그것이 그 이후로 고쳐 졌다고 생각하지만, 이러한 '사소한 세부 사항'이 언제 다시 당신을 괴롭힐 지 알 수 없습니다.

• 절대로 UTC 오프셋 (또는 시간대 참조)없이 현지 시간을 저장하지 마십시오. FAT32와 C struct tm를 포함하지 않는 방법의 예 ¹
• 표준 시간대는
  • UTC 오프셋 세트 (예 : 겨울에는 +0100, 여름에는 +0200)
  • 전환이 발생하는시기에 대한 규칙 (시간에 따라 변경 될 수 있음 : 예를 들어 1990 년대 EU는 전환이 3 월과 10 월 마지막 일요일 02:00 표준시 / 03 : 00 DST로 전환을 조정했습니다. 회원국 간).

¹ 일부 구현은 struct tmUTC 오프셋을 저장하지만 표준으로 만들지는 않았습니다.

데이터베이스 (특히 MySQL 이지만 대부분의 데이터베이스에 적용됨)를 처리 할 때 UTC를 저장하기가 어렵다는 것을 알았습니다.

• 데이터베이스는 일반적으로 기본적으로 서버 날짜 시간 (CURRENT_TIMESTAMP)으로 작동합니다.
• 서버 시간대를 변경하지 못할 수 있습니다.
• 시간대를 변경할 수 있더라도 서버 시간대가 로컬 일 것으로 예상되는 타사 코드가있을 수 있습니다.

데이터베이스에 서버 날짜 시간을 저장하고 SQL 문에서 데이터베이스가 저장된 날짜 시간을 UTC (즉, UNIX_TIMESTAMP ())로 다시 변환하도록하는 것이 더 쉽다는 것을 알았습니다. 그런 다음 날짜 시간을 코드에서 UTC로 사용할 수 있습니다.

서버와 모든 코드를 100 % 제어 할 수 있다면 서버 시간대를 UTC로 변경하는 것이 좋습니다.