DateTime 및 DateTimeZone 클래스에서 제공하는 기본 표준 시간대 변환을 사용합니다. DateTimeZone::listAbbreviations() 사용할 때 주의하십시오. 답변을 참조하십시오. PHP를 최신 Olson 데이터로 유지하려면 timezonedb PECL 패키지를 주기적으로 설치하십시오. 답변을 참조하십시오 .
시간대 변환에 Boost 를 사용하지 마십시오. API가 표준 IANA(일명 "zoneinfo") 식별자를 지원한다고 주장하지만 각 영역에 있을 수 있는 풍부한 변경 기록을 고려하지 않고 이를 POSIX 스타일 데이터에 대략적으로 매핑합니다. (또한 파일은 유지 관리에서 빠졌습니다.)
대부분의 비즈니스 규칙은 UTC 또는 GMT가 아닌 민간 시간을 사용합니다. 따라서 응용 프로그램 논리를 적용하기 전에 UTC 타임스탬프를 현지 시간대로 변환할 계획입니다.
시간대와 오프셋은 고정되어 있지 않으며 변경될 수 있음을 기억하십시오. 예를 들어, 역사적으로 미국과 영국은 동일한 날짜를 '앞으로 봄'과 '뒤로'를 사용했습니다. 그러나 2007년 미국은 시계가 바뀌는 날짜를 변경했습니다. 이것은 이제 일년 중 48주 동안 런던 시간과 뉴욕 시간의 차이가 5시간이고 4주 동안(봄에는 3시간, 가을에는 1시간) 차이가 4시간임을 의미합니다. 여러 영역을 포함하는 계산에서 이와 같은 항목에 유의하십시오.
시간 유형(실제 이벤트 시간, 브로드캐스트 시간, 상대 시간, 과거 시간, 반복 시간)을 고려하여 올바른 검색을 위해 저장해야 하는 요소(타임스탬프, 시간대 오프셋 및 시간대 이름) - "시간 유형" 참조 이 대답 .
OS, 데이터베이스 및 애플리케이션 tzdata 파일을 자신과 전 세계 간에 동기화된 상태로 유지하십시오.
서버에서 하드웨어 시계와 OS 시계를 현지 시간대가 아닌 UTC로 설정하십시오.
에 관계없이 이전 글 머리, 서버 측 코드는 웹 사이트를 포함하여 서버의 로컬 시간대가 특히 무엇이든 될 것으로 기대해서는 안됩니다. 답변을 참조하십시오 .
구성 파일 설정이나 기본값을 통해 전역적으로 작업하는 것보다 애플리케이션 코드에서 사례별로 표준 시간대를 사용하는 것을 선호합니다.
America/New_York 와 같은 "시간대"를 -05:00 같은 "시간대 오프셋"과 혼동하지 마십시오. 그들은 두 가지 다른 것입니다. 시간대 태그 위키를 참조하십시오.
ECMAScript 5.1 이하에는 일광 절약 시간을 잘못 사용할 수 있는 설계 결함 이 있으므로 JavaScript의 Date 객체를 사용하여 이전 웹 브라우저에서 날짜 및 시간 계산을 수행하지 마십시오. (이것은 ECMAScript 6 / 2015에서 수정되었습니다.)
고객의 시계를 절대 신뢰하지 마십시오. 매우 잘못된 것일 수 있습니다.
사람들에게 "항상 모든 곳에서 UTC를 사용하라"고 말하지 마십시오. 이 광범위한 조언은 이 문서의 앞부분에서 설명한 몇 가지 유효한 시나리오에 대한 근시안적입니다. 대신 작업 중인 데이터에 적절한 시간 참조를 사용하십시오. ( 타임스탬프 는 UTC를 사용할 수 있지만 미래의 시간 예약 및 날짜 전용 값은 사용할 수 없습니다.)
테스트:
테스트 할 때, 반드시 서부, 동부, 북부와 국가 시험 만든다 남부 진행중인 두 DST와, (세계의 각 분기에 그렇게 4 개 지역을 사실) 반구를하지 (8 제공)을 수행하는 국가 DST를 사용하지 마십시오(모든 지역을 포괄하는 또 다른 4개, 총 12개).
DST의 전환을 테스트합니다. 즉, 현재 여름 시간에 있을 때 겨울에서 시간 값을 선택합니다.
이벤트 시간: 예: 국제 스포츠 이벤트가 발생한 시간 또는 대관식/사망 등. 이는 시청자가 아닌 이벤트의 시간대에 따라 다릅니다.
텔레비전 시간: 예를 들어, 특정 TV 쇼는 현지 시간으로 전 세계적으로 오후 9시에 방송됩니다. 웹사이트에 결과(예: American Idol)를 게시할 때 중요합니다.
상대 시간: 예: 이 질문에는 21시간 후에 공개 현상금이 마감됩니다. 이것은 표시하기 쉽습니다
반복 시간: 예: TV 쇼는 DST가 변경되더라도 매주 월요일 오후 9시에 있습니다.
역사/대체 시간도 있습니다. 표준 시간으로 다시 매핑되지 않을 수 있기 때문에 성가신 일입니다. 예: 율리우스력 날짜, 토성의 음력 달력에 따른 날짜, 클링온 달력.
시작/종료 타임스탬프를 UTC로 저장하면 잘 작동합니다. 1의 경우 이벤트 시간대 이름 + 이벤트와 함께 저장된 오프셋이 필요합니다. 2의 경우 각 지역에 저장된 현지 시간 식별자와 모든 시청자에 대해 저장된 현지 시간대 이름 + 오프셋이 필요합니다(긴급 상황에 처한 경우 IP에서 이를 파생시킬 수 있음). 3의 경우 UTC 초로 저장하고 시간대가 필요하지 않습니다. 4는 전역 이벤트인지 로컬 이벤트인지에 따라 1 또는 2의 특수한 경우이지만, 이 이벤트가 생성되기 전이나 생성된 후에 시간대 정의가 변경되었는지 여부를 알 수 있도록 생성된 타임스탬프도 저장해야 합니다. 이는 기록 데이터를 표시해야 하는 경우에 필요합니다.
저장 시간
항상 UTC로 시간 저장
표시되는 현지 시간으로 변환(현지 시간은 데이터를 보고 있는 사용자에 의해 정의됨)
시간대를 저장할 때 이름, 타임스탬프 및 오프셋이 필요합니다. 이것은 정부가 때때로 시간대의 의미를 변경하기 때문에 필요합니다(예: 미국 정부가 DST 날짜를 변경함). 애플리케이션은 일을 정상적으로 처리해야 합니다... 예: LOST의 에피소드가 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년 5월 1일부터 1937년 6월 30일까지 법에 의해 UTC보다 정확히 19분 32.13초 빨랐습니다. 이 시간대는 HH:MM 형식을 사용하여 정확하게 나타낼 수 없습니다.
알겠습니다. 끝입니다.
Community Wiki
이것은 중요하고 놀랍도록 어려운 문제입니다. 진실은 지속 시간에 대해 완전히 만족스러운 기준이 없다는 것입니다. 예를 들어, SQL 표준과 ISO 형식(ISO 8601)은 분명히 충분하지 않습니다.
개념적 관점에서 하나는 일반적으로 두 가지 유형의 시간-날짜 데이터를 다루며, 이를 구별하는 것이 편리합니다(위 표준은 그렇지 않음): " 물리적 시간 " 및 " 시민 시간 ".
시간의 "물리적" 순간은 물리학이 다루는 연속적인 우주 타임라인의 한 지점입니다(물론 상대성 이론은 무시합니다). 이 개념은 예를 들어 (윤초를 무시할 수 있는 경우) UTC로 적절하게 코드화되고 유지될 수 있습니다.
"시민" 시간은 시민 규범을 따르는 날짜/시간 사양입니다. 여기서 특정 시점은 날짜/시간 필드 세트(Y,M,D,H,MM,S,FS)와 TZ(시간대 사양)로 완전히 지정됩니다. (실제로는 "달력"이기도 하지만 논의를 그레고리력으로 제한한다고 가정하겠습니다). 표준 시간대와 달력을 함께 사용하면 (원칙적으로) 한 표현에서 다른 표현으로 매핑할 수 있습니다. 그러나 시민 및 물리적 시간 순간은 근본적으로 다른 유형의 크기이며 개념적으로 분리된 상태로 유지되고 다르게 처리되어야 합니다(유추: 바이트 및 문자열 배열).
우리는 이러한 유형의 사건을 서로 바꾸어 말할 수 있고 시민 시대는 정치적인 변화의 대상이기 때문에 문제가 혼란스럽습니다. 문제(그리고 이러한 개념을 구별할 필요성)는 미래의 사건에 대해 더욱 분명해집니다. 예(여기에서 내 토론 에서 가져옴 .
2019-Jul-27, 10:30:00 , TZ= Chile/Santiago , (GMT-4를 오프셋하므로 UTC 2019-Jul-27 14:30:00 해당하는 일부 이벤트에 대한 알림을 자신의 캘린더에 기록합니다. 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 ?
2019-Jul-27, 10:30:00 TZ=Chile/Santiago 전화해 주세요"라고 말했을 때 개념적으로 무엇을 의미했는지 아는 사람이 없으면 정답은 없습니다.
그는 "시민의 날짜-시간"("우리 도시의 시계가 10시 30분을 가리킬 때")을 의미했나요? 이 경우 A)가 정답입니다.
아니면 우리 우주의 연속적인 시간선에 있는 한 지점인 "시간의 물리적 순간", 즉 "다음 일식이 일어날 때"를 의미했습니까? 이 경우 답 B)가 정답입니다.
몇 가지 날짜/시간 API는 이러한 구분을 올바르게 합니다. 그 중 Jodatime 은 다음(세 번째!) Java DateTime API(JSR 310)의 기초입니다.
Community Wiki
어떤 계층이 사용자와 상호 작용하는지 정확히 파악하고 표준 표현(UTC)에서 날짜-시간을 변경해야 하는 문제를 아키텍처에서 명확하게 구분합니다. UTC가 아닌 날짜-시간은 표시 (사용자의 현지 시간대를 따름)이고 UTC 시간은 모델 (백엔드 및 중간 계층에 대해 고유함)입니다.
또한 실제 청중이 무엇인지, 제공할 필요가 없는 것은 무엇이며, 어디에 선을 그어야 하는지 결정하십시오 . 실제로 중요한 고객이 있는 경우가 아니면 이국적인 캘린더를 만지지 마십시오. 그런 다음 해당 지역에 대해서만 별도의 사용자 대면 서버를 고려하십시오.
사용자의 위치를 확보하고 유지할 수 있는 경우 체계적인 날짜-시간 변환(예: .NET 문화권 또는 SQL 테이블)을 위해 위치를 사용하지만 날짜-시간이 사용자에게 중요한 경우 최종 사용자가 재정의를 선택할 수 있는 방법을 제공합니다.
관련된 과거 감사 의무가 있는 경우 (예: AZ의 Jo가 2년 전 9월에 청구서를 지불한 정확한 시간을 말하는 것과 같이) 기록 을 위해 UTC와 현지 시간 을 모두 보관하십시오(변환 테이블은 시간 경과에 따라 변경됩니다).
파일, 웹 서비스 등과 같이 대량으로 제공되는 데이터에 대한 시간 참조 표준 시간대를 정의합니다 . 동부 해안 회사가 CA에 데이터 센터를 가지고 있다고 가정해 보겠습니다. 둘 중 하나를 가정하는 대신 표준으로 사용하는 것이 무엇인지 물어보고 알아야 합니다.
날짜-시간의 텍스트 표현에 포함된 표준 시간대 오프셋을 신뢰하지 말고 구문 분석하고 따르지 마십시오. 대신 항상 표준 시간대 및/또는 참조 영역을 명시적으로 정의해야 합니다. PST 오프셋으로 시간을 쉽게 수신할 수 있지만 클라이언트의 기준 시간이고 레코드가 PST에 있는 서버에서 방금 내보냈기 때문에 시간은 실제로 EST입니다.
Community Wiki
ftp://elsie.nci.nih.gov/pubhttp://iana.org/time-zones/ 에서 구할 수 있는 Olson tz 데이터베이스 에 대해 알아야 합니다. 매년 여러 번 업데이트되어 전 세계 여러 국가에서 겨울과 여름(표준 및 일광 절약 시간) 시간을 전환해야 하는 시기(및 여부)의 자주 변경됩니다. 2009년에 마지막 릴리스는 2009년이었습니다. 2010년에는 2010n이었습니다. 2011년에는 2011년이었습니다. 2012년 5월 말에 릴리스는 2012c였습니다. 두 개의 개별 아카이브(tzcode20xxy.tar.gz 및 tzdata20xxy.tar.gz)에 데이터와 실제 시간대 데이터 자체를 관리하는 코드 세트가 있습니다. 코드와 데이터 모두 공개 도메인에 있습니다.
이것은 America/Los_Angeles(및 US/Pacific과 같은 동의어)와 같은 시간대 이름의 소스입니다.
다른 영역을 추적해야 하는 경우 Olson 데이터베이스가 필요합니다. 다른 사람들이 조언했듯이 데이터가 생성된 시간대의 레코드와 함께 고정된 형식(일반적으로 UTC가 선택되는 형식)으로 데이터를 저장하기를 원합니다. 시간과 표준 시간대 이름의 UTC 오프셋을 구별할 수 있습니다. 나중에 차이를 만들 수 있습니다. 또한 현재 2010-03-28T23:47:00-07:00(미국/태평양)임을 알고 있으면 PST( PDT(태평양 일광 절약 시간)가 아닌 태평양 표준시).
표준 C 라이브러리 인터페이스는 이런 종류의 작업에 크게 도움이 되지 않습니다.
Olson 데이터는 부분적으로 AD Olson이 곧 은퇴할 것이기 때문에 그리고 부분적으로는 저작권 침해에 대한 유지 관리자에 대한 (현재 기각된) 소송이 있었기 때문에 이동되었습니다. 시간대 데이터베이스는 이제 IANA( Internet Assigned Numbers Authority) 의 후원하에 관리되며 첫 페이지에 'Time Zone Database' 에 대한 링크가 있습니다. 토론 메일링 리스트는 현재 tz@iana.org . 발표 목록은 tz-announce@iana.org 입니다.
Community Wiki
일반적으로 저장된 타임스탬프에 현지 시간 오프셋(DST 오프셋 포함) 을 포함합니다. 나중에 타임스탬프를 원래 시간대(및 DST 설정)로 표시하려는 경우 UTC만으로는 충분하지 않습니다.
오프셋이 항상 정수 시간인 것은 아닙니다(예: 인도 표준시는 UTC+05:30임).
예를 들어, 적절한 형식은 튜플(유닉스 시간, 분 단위 오프셋) 또는 ISO 8601 입니다.
Community Wiki
"컴퓨터 시간"과 "사람 시간"의 경계를 넘는 것은 악몽입니다. 가장 중요한 것은 시간대와 일광 절약 시간을 관리하는 규칙에 대한 일종의 표준이 없다는 것입니다. 국가는 언제든지 시간대 및 DST 규칙을 자유롭게 변경할 수 있습니다.
일부 국가(예: 이스라엘, 브라질)는 매년 일광 절약 시간제를 적용할 시기를 결정하므로 DST가 언제 시행되는지 미리 알 수 없습니다. 다른 사람들은 DST가 언제 시행되는지에 대한 고정된(ish) 규칙을 가지고 있습니다. 다른 국가에서는 DST를 모두 사용하지 않습니다.
시간대는 GMT와 1시간 차이일 필요가 없습니다. 네팔은 +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개)가 있는 서반구 및 동부 반구의 국가를 테스트해야 합니다.
Community Wiki
PHP의 경우:
PHP > 5.2의 DateTimeZone 클래스는 이미 다른 사람들이 언급한 Olson DB를 기반으로 하므로 DB가 아닌 PHP에서 시간대 변환을 수행하는 경우 (이해하기 어려운) Olson 파일 작업에서 면제됩니다.
그러나 PHP는 Olson DB만큼 자주 업데이트되지 않으므로 PHP의 시간대 변환만 사용하면 오래된 DST 정보를 남기고 데이터의 정확성에 영향을 미칠 수 있습니다. 이 자주 일어날 것으로 예상되지는 않지만,이 발생할 수 있습니다, 당신은 전 세계적으로 많은 사용자 기반을 가지고있는 경우 발생합니다.
위의 문제를 해결하려면 timezonedb pecl 패키지를 사용하십시오. 그 기능은 PHP의 시간대 데이터를 업데이트하는 것입니다. 업데이트될 때마다 이 패키지를 설치하십시오. (이 패키지에 대한 업데이트가 Olson 업데이트를 정확히 따르는지는 확실하지 않지만 적어도 Olson 업데이트 빈도에 매우 가까운 빈도로 업데이트되는 것 같습니다.)
Community Wiki
디자인이 이를 수용할 수 있다면 현지 시간 변환을 함께 피하십시오!
나는 이것이 미친 소리처럼 들릴 수도 있다는 것을 알고 있지만 UX에 대해 생각해 보십시오. 사용자는 언뜻 보면 절대 날짜(2010.09.17, 금요일 9월 17일)보다 가까운 상대적 날짜(오늘, 어제, 다음 월요일)를 처리합니다. now() 가까울수록 시간대(및 DST)의 정확도가 더 중요하므로 +/- 1주 또는 2주 동안 날짜/날짜/시간을 상대적 형식으로 표현할 수 있다면, 나머지 날짜는 UTC가 될 수 있으며 사용자의 95%에게는 그다지 중요하지 않습니다.
이렇게 하면 모든 날짜를 UTC로 저장하고 UTC로 상대 비교를 수행하고 상대 날짜 임계값을 벗어난 UTC 날짜를 사용자에게 간단히 표시할 수 있습니다.
이것은 사용자 입력에도 적용될 수 있습니다(그러나 일반적으로 더 제한된 방식으로). { 어제, 오늘, 내일, 다음 월요일, 다음 목요일 }만 있는 드롭다운에서 선택하는 것이 날짜 선택기보다 훨씬 간단하고 쉽습니다. 날짜 선택기는 양식 작성에서 가장 고통스러운 구성 요소 중 일부입니다. 물론 이것이 모든 경우에 작동하는 것은 아니지만 매우 강력하게 만들기 위해서는 약간의 영리한 디자인만 필요하다는 것을 알 수 있습니다.
Community Wiki
나는 최근에 Ajax 포스트백에서 내 서버 측 코드로 되돌아오는 datetime이 제공된 datetime과 다른 웹 애플리케이션에 문제가 있었습니다.
JavaScript가 표준 시간대 및 일광 절약 시간에 맞게 조정되고 일부 브라우저에서는 일광 절약 시간을 적용할 시기를 계산하기 때문에 클라이언트에 다시 게시할 날짜를 문자열로 구축한 클라이언트의 JavaScript 코드와 관련이 있을 가능성이 큽니다. 남들과 다른 것 같았다.
결국 나는 클라이언트에서 날짜 및 시간 계산을 완전히 제거하기로 선택했고 정수 키로 내 서버에 다시 게시한 다음 서버의 날짜 시간으로 변환하여 일관된 변환을 허용했습니다.
이것에서 얻은 교훈: 꼭 필요한 경우가 아니면 웹 애플리케이션에서 JavaScript 날짜 및 시간 계산을 사용하지 마십시오.
Community Wiki
시도하지는 않았지만 시간대 조정에 대한 접근 방식은 다음과 같습니다.
모든 것을 UTC로 저장하십시오.
RegionClassId, StartDateTime 및 OffsetMinutes(int, 분 단위)의 세 열이 있는 TZOffsets 테이블을 만듭니다.
표에서 얼마나 많은하여 로컬 시간이 변경 될 때 날짜와 시간의 목록을 저장합니다. 표의 지역 수와 날짜 수는 지원해야 하는 날짜 범위와 세계 지역에 따라 다릅니다. 날짜가 실제적인 한계까지 미래를 포함해야 하지만 "과거" 날짜인 것처럼 이것을 생각하십시오.
UTC 시간의 현지 시간을 계산해야 하는 경우 다음을 수행하십시오.
SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime FROM TZOffsets WHERE StartDateTime <= @inputdatetime AND RegionClassId = @RegionClassId;
앱에서 이 테이블을 캐시하고 데이터베이스를 적중하는 대신 LINQ 또는 유사한 방법을 사용하여 쿼리를 수행할 수 있습니다.
코드에 규칙이 적용되지 않으므로 새 지역이나 날짜 범위에 대한 오프셋을 쉽게 조정할 수 있습니다.
모든 날짜 또는 지역 범위를 지원할 필요는 없으며 필요에 따라 추가할 수 있습니다.
지역은 지정학적 경계에 직접 대응할 필요가 없으며 행의 중복을 피하기 위해(예를 들어, 미국의 대부분의 주는 DST를 동일한 방식으로 처리함) 다른 테이블에서 보다 전통적인 목록에 연결하는 광범위한 RegionClass 항목을 가질 수 있습니다. 주, 국가 등
DST의 시작 날짜와 종료 날짜가 지난 몇 년 동안 변경된 미국과 같은 상황의 경우 이는 처리하기가 매우 쉽습니다.
StartDateTime 필드도 시간을 저장할 수 있으므로 오전 2시 표준 변경 시간을 쉽게 처리할 수 있습니다.
전 세계 모든 곳에서 1시간 DST를 사용하는 것은 아닙니다. 이것은 이러한 경우를 쉽게 처리합니다.
데이터 테이블은 크로스 플랫폼이며 거의 모든 데이터베이스 플랫폼이나 프로그래밍 언어를 사용하는 개발자가 사용할 수 있는 별도의 오픈 소스 프로젝트일 수 있습니다.
이것은 표준 시간대와 관련이 없는 오프셋에 사용할 수 있습니다. 예를 들어, 지구 자전을 조정하기 위해 때때로 발생하는 1초 조정, 그레고리력 내에서 및 그레고리력 등의 역사적 조정이 있습니다.
이것은 데이터베이스 테이블에 있기 때문에 표준 보고서 쿼리 등은 비즈니스 로직 코드를 통해 이동하지 않고 데이터를 활용할 수 있습니다.
이것은 원하는 경우 표준 시간대 오프셋도 처리하고 지역이 다른 표준 시간대에 할당된 특별한 역사적 사례를 고려할 수도 있습니다. 시작 날짜가 최소인 각 지역에 시간대 오프셋을 할당하는 초기 날짜만 있으면 됩니다. 이렇게 하려면 각 시간대에 대해 하나 이상의 지역을 만들어야 하지만 "1989년 2월 2일 오전 5시에 애리조나 주 유마와 워싱턴 주 시애틀 간의 현지 시간 차이는 얼마입니까?"와 같은 흥미로운 질문을 할 수 있습니다. (다른 것에서 하나의 SUM()을 빼십시오).
자,이 방법 또는 기타의 유일한 단점은 클럭 오프셋 음이있는 DST 변화가 주어진 현지 시간을 반복하기 때문에 현지 시간부터 GMT로 변환이 완벽하게되지 않은 것입니다. 이 문제를 쉽게 처리할 수 있는 방법은 없습니다. 현지 시간을 저장하는 것이 애초에 나쁜 소식인 이유 중 하나입니다.
Community Wiki
저는 두 가지 유형의 시스템, 즉 "교대 계획 시스템(예: 공장 근로자)"과 "가스 의존 관리 시스템)에서 이것을 쳤습니다.
하루 23시간과 25시간은 견디기 힘든 고통이며, 7시간이나 9시간이 걸리는 8시간 교대도 마찬가지입니다. 문제는 각 고객 또는 심지어 고객의 부서마다 이러한 특별한 경우에 수행하는 작업에 대해 만든(종종 문서화 없이) 다른 규칙이 있다는 것을 알게 될 것입니다.
일부 질문은 고객이 "기성품" 소프트웨어에 대한 비용을 지불할 때까지 묻지 않는 것이 좋습니다. 소프트웨어를 구입할 때 이러한 유형의 문제를 미리 생각하는 고객은 매우 드뭅니다.
모든 경우에 UTC로 시간을 기록하고 날짜/시간을 저장하기 전에 현지 시간으로/로 변환해야 한다고 생각합니다. 그러나 일광 절약 시간제와 시간대를 사용하면 주어진 시간에 어느 시간이 걸리는지 아는 것조차 어려울 수 있습니다.
Community Wiki
웹 사이트 및 기타 백엔드 서비스를 포함하여 서버에서 실행되는 애플리케이션의 경우 애플리케이션에서 서버의 시간대 설정을 무시해야 합니다.
일반적인 조언은 서버의 시간대를 UTC로 설정하는 것입니다. 이것은 실제로 좋은 모범 사례이지만 다른 모범 사례를 따르지 않는 응용 프로그램에 대한 반창고입니다. 예를 들어 서비스가 UTC 기반 타임스탬프 대신 로컬 타임스탬프를 사용하여 로그 파일에 기록할 수 있으므로 일광 절약 시간 대체 전환 중에 모호성이 생성될 수 있습니다. 서버의 시간대를 UTC로 설정하면 해당 응용 프로그램이 수정됩니다. 그러나 실제 수정은 응용 프로그램이 UTC를 사용하여 시작하는 것입니다.
웹 사이트를 포함하여 서버 측 코드는 서버의 로컬 시간대가 특히 무엇이든 될 것으로 기대해서는 안됩니다.
일부 언어에서는 현지 시간대가 애플리케이션 코드에 쉽게 들어갈 수 있습니다. 예를 들어, DateTime.ToUniversalTime .NET의 방법은 UTC 로컬 시간대 및 변환됩니다DateTime.Now 속성을 반환 로컬 타임 존의 현재 시간. 또한 Date 생성자는 컴퓨터의 현지 시간대를 사용합니다. 이와 같은 다른 예가 많이 있습니다. 컴퓨터의 현지 시간대 설정을 사용하는 코드를 피하면서 방어적인 프로그래밍을 연습하는 것이 중요합니다.
데스크톱 애플리케이션, 모바일 애플리케이션 및 클라이언트 측 JavaScript와 같은 클라이언트 측 코드에 대해 현지 시간대를 사용하여 예약합니다.
이 PHP 메서드는 일부 '주요' 시간대(예: CEST)를 포함하는 연관 배열을 반환합니다. 여기에는 자체적으로 더 구체적인 '지리적' 시간대(예: 유럽/암스테르담)가 포함됩니다.
이러한 시간대와 오프셋/DST 정보를 사용하는 경우 다음 사항을 인식하는 것이 매우 중요합니다.
각 시간대의 다른 오프셋/DST 구성 (이력 구성 포함)이 모두 포함된 것 같습니다!
예를 들어, Europe/Amsterdam은 이 함수의 출력에서 6번 찾을 수 있습니다. 두 번 발생(오프셋 1172/4772)은 1937년까지 사용된 암스테르담 시간에 대한 것입니다. 2개(1200/4800)는 1937년에서 1940년 사이에 사용된 시간입니다. 2개(3600/4800)는 1940년 이후 사용된 시간입니다.
따라서 이 함수가 반환하는 오프셋/DST 정보 가 현재 올바른/사용 중인 것으로 신뢰할 수 없습니다!
특정 시간대의 현재 오프셋/DST를 알고 싶다면 다음과 같이 해야 합니다.
<?php $now = new DateTime(null, new DateTimeZone('Europe/Amsterdam')); echo $now->getOffset(); ?>
Community Wiki
DST가 활성화된 상태에서 실행 중인 데이터베이스 시스템을 유지 관리하는 경우 가을에 전환하는 동안 시스템을 종료해야 하는지 여부를 주의 깊게 확인하십시오. Mandy DBS(또는 다른 시스템도 마찬가지)는 (로컬) 시간에 같은 지점을 두 번 전달하는 것을 좋아하지 않습니다. 이는 가을에 시계를 되돌릴 때 정확히 일어나는 일입니다. SAP는 (IMHO 정말 깔끔한) 해결 방법으로 이 문제를 해결했습니다. 시계를 되돌리는 대신 내부 시계가 2시간 동안 평소의 절반 속도로 실행되도록 했습니다...
Community Wiki
.NET 프레임워크 를 사용하고 있습니까? 그렇다면 .NET 3.5에 추가된 DateTimeOffset 유형을 소개하겠습니다.
이 구조는 DateTimeOffset 인스턴스의 날짜 및 시간과 UTC(협정 세계시) 간의 차이를 지정 DateTime 및 Offset( TimeSpan
DateTimeOffset.Now 정적 메서드는 현재(로컬) 시간과 로컬 오프셋(운영 체제의 지역 정보에 정의됨)으로 구성된 DateTimeOffset
DateTimeOffset.UtcNow 정적 메서드는 UTC(그리니치에 있는 것처럼)의 현재 시간으로 구성된 DateTimeOffset
비즈니스 규칙은 항상 시민 시간에 작동해야 합니다(달리 언급하는 법률이 없는 한). 시민 시간은 엉망이지만 사람들이 사용하는 시간이므로 중요합니다.
내부적으로 타임스탬프를 에포크로부터의 시민 시간 초로 유지합니다. Epoch 는 특별히 중요하지 않지만(저는 Unix Epoch를 선호합니다) 대안보다 작업을 더 쉽게 만듭니다. 윤초가 정말로 필요한 작업(예: 위성 추적)을 하지 않는 한 윤초가 존재하지 않는 척하십시오. 타임스탬프와 표시된 시간 간의 매핑은 DST 규칙을 적용해야 하는 유일한 지점입니다. 규칙은 자주 변경되므로(전 세계적으로 1년에 여러 번, 정치인을 비난함) 매핑을 하드 코딩하지 않도록 해야 합니다. Olson의 TZ 데이터베이스 는 매우 중요합니다.
Community Wiki
부정확하거나 적어도 혼란스러워 보이는 두 가지를 지적하고 싶었습니다.
일광 절약 시간제에 영향을 받지 않는 통합 표준에 따라 항상 시간을 유지합니다. GMT와 UTC는 다른 사람들에 의해 언급되었지만 UTC가 가장 자주 언급되는 것 같습니다.
(거의) 모든 실용적인 컴퓨팅 목적을 위해 UTC는 사실 GMT입니다. 소수의 초가 있는 타임스탬프가 표시되지 않는 한 GMT를 처리하는 것이므로 이러한 구분이 중복됩니다.
타임스탬프를 저장할 때 현지 시간 오프셋을 있는 그대로(DST 오프셋 포함) 포함합니다.
타임스탬프는 항상 GMT로 표시되므로 오프셋이 없습니다.
Community Wiki
내 경험은 다음과 같습니다.
(타사 라이브러리가 필요하지 않음)
서버 측에서는 데이터베이스의 모든 날짜/시간 값이 사용자, 서버, 시간대 또는 DST의 위치에 관계없이 단일 표준에 있도록 시간을 UTC 형식으로 저장합니다.
UI 레이어나 사용자에게 발송되는 이메일에는 사용자별로 시간을 표시해야 합니다. 이를 위해 사용자의 시간대 오프셋이 있어야 이 오프셋을 데이터베이스의 UTC 값에 추가하여 사용자의 현지 시간이 됩니다. 사용자가 가입할 때 사용자의 시간대 오프셋을 가져오거나 웹 및 모바일 플랫폼에서 자동으로 감지할 수 있습니다. 웹 사이트의 경우 JavaScript의 함수 getTimezoneOffset() 메서드는 버전 1.0부터 표준이며 모든 브라우저와 호환됩니다. (참고: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )
사모아 (태평양에 있는 섬)는 호주와 뉴질랜드와의 거래를 쉽게 하기 위해 시간대를 24시간 앞당겼습니다.
2명의 인구가 서로 다른 시간대를 따르는 웨스트 뱅크(West Bank),
18세기는 율리우스 력에서 그레고리력으로 변경 됩니다(러시아에서는 20세기에 일어났습니다).
Community Wiki
처리 시간이 설명된 거대한 혼란이며 결코 안주할 수 없음을 증명하는 한 가지 예입니다. 이 페이지의 여러 지점에서 윤초가 무시되었습니다.
몇 년 전 Android 운영 체제는 GPS 위성을 사용하여 UTC 시간 참조를 얻었지만 GPS 위성이 윤초를 사용하지 않는다는 사실을 무시했습니다. 애플 폰 사용자와 안드로이드 폰 사용자가 약 15초 간격으로 카운트다운을 하던 섣달 그믐날 혼란이 생기기 전까지 아무도 눈치채지 못했습니다.
그 이후로 문제가 해결되었다고 생각하지만 이러한 '사소한 세부 사항'이 언제 다시 나타날지 모릅니다.
Community Wiki
실제로 kernel32.dll은 SystemTimeToTzSpecificLocation을 내보내지 않습니다. 그러나 SystemTimeToTzSpecificLocalTime 및 TzSpecificLocalTimeToSystemTime...
Community Wiki
다음과 같은 생성자에만 의존하지 마십시오.
new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)
DST로 인해 특정 날짜 시간이 존재하지 않는 경우 예외를 throw할 수 있습니다. 대신, 그러한 날짜를 생성하기 위한 고유한 방법을 구축하십시오. 그 중 DST로 인해 발생하는 모든 예외를 포착하고 전환 오프셋으로 필요한 시간을 조정합니다. DST는 시간대에 따라 다른 날짜와 다른 시간(브라질의 경우 자정)에 발생할 수 있습니다.
Community Wiki
UTC 오프셋(또는 시간대에 대한 참조) 없이 현지 시간을 절대 저장하지 마십시오. 저장하지 않는 방법의 예에는 C의 FAT32 및 struct tm 이 있습니다.¹
시간대가 다음의 조합임을 이해하십시오.
UTC 오프셋 세트(예: 겨울에는 +0100, 여름에는 +0200)
전환이 발생하는 시기에 대한 규칙(시간이 지남에 따라 변경될 수 있음: 예를 들어 1990년대에 EU는 전환이 3월과 10월의 마지막 일요일, 표준시 02:00/DST 03:00 DST에 있는 것으로 조정했습니다. 회원국 간).
struct tm 의 일부 구현은 UTC 오프셋을 저장하지만 이것은 표준으로 만들지 않았습니다.
Community Wiki
데이터베이스(특히 MySQL , 그러나 이것은 대부분의 데이터베이스에 적용됨)를 다룰 때 UTC를 저장하는 것이 어렵다는 것을 알았습니다.
데이터베이스는 일반적으로 기본적으로 서버 datetime과 함께 작동합니다(즉, CURRENT_TIMESTAMP).
서버 시간대를 변경하지 못할 수 있습니다.
시간대를 변경할 수 있는 경우에도 서버 시간대가 로컬일 것으로 예상하는 타사 코드가 있을 수 있습니다.
서버 날짜 시간을 데이터베이스에 저장한 다음 데이터베이스가 SQL 문에서 저장된 날짜 시간을 UTC(즉, UNIX_TIMESTAMP())로 다시 변환하도록 하는 것이 더 쉽다는 것을 알았습니다. 그런 다음 코드에서 날짜/시간을 UTC로 사용할 수 있습니다.
서버와 모든 코드를 100% 제어할 수 있다면 서버 시간대를 UTC로 변경하는 것이 더 나을 것입니다.