| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 8. 데이터 타입 | Fast Forward | Next |
PostgreSQL에서는,Table 8-9에 나타나고 있는SQL의 일자와 시각 데이터형의 모두가 서포트되고 있습니다. 이러한 데이터형으로 이용할 수 있는 연산자에 대해서는Section 9.9으로 설명합니다.
Table 8-9. 날짜/시각 데이터형
| 이름 | 저장 크기 | 설명 | 낮은 값 | 높은 값 | 해결 |
|---|---|---|---|---|---|
| timestamp [ ( p ) ] [ without time zone ] | 8 바이트 | 일자와 시각 양쪽 모두 | 4713 BC | 5874897 AD | 1μ초, 14 자리수 |
| timestamp [ ( p ) ] with time zone | 8바이트 | 일자와 시각 양쪽 모두, 시간대 첨부 | 4713 BC | 5874897 AD | 1μ초, 14 자리수 |
| interval [ ( p ) ] | 12바이트 | 시간 간격 | -178000000년 | 178000000년 | 1μ초, 14 자리수 |
| date | 4바이트 | 일자만 | 4713 BC | 5874897 AD | 1일 |
| time [ ( p ) ] [ without time zone ] | 8바이트 | 그 날의 시각만 | 00:00:00 | 24:00:00 | 1μ초, 14 자리수 |
| time [ ( p ) ] with time zone | 12바이트 | 그 날의 시각만, 시간대 첨부 | 00:00:00+1459 | 24:00:00-1459 | 1μ초, 14 자리수 |
Note: PostgreSQL 7.3보다 이전으로는, 단순한timestamp는timestamp with time zone와 같았습니다. 이것은, SQL 호환성을 위해서 변경되었습니다.
time,timestamp, 및interval는 초필드에 보유되고 있는 소수점 이하의 자리수를 지정하는 옵션의 정밀도치인 p 를 받아들입니다. 디폴트에서는, 명시적인 정밀도에 대한 한계는 없습니다. p 의 허용 범위는,timestamp형과interval형의 경우는 0에서 6입니다.
Note: timestamp의 값이 배정밀도 부동 소수점수(실수)로서 보존되고 있는 경우(현재의 디폴트입니다), 유효한 정밀도는 6보다 작을지도 모릅니다. timestamp의 값은2000-01-01심야를 기준으로 한 경과초 수라고 해 저장됩니다. 마이크로 세컨드의 정밀도는,2000-01-01으로부터 2, 3년 이내의 일자에서는 달성되고 있습니다만, 그 정밀도는 일자가(2000-01-01로부터) 떨어지는 것에 따라 악화됩니다. timestamp의 값이 8바이트 정수(컴파일시에 옵션지정)로서 저장될 때에는 마이크로 세컨드의 정밀도는 모든 범위의 값에 관해서 유효합니다. 그러나, 8바이트 정수의 타임 스탬프에서는, 그 일자 범위가 상술의 제한보다 제한되어 4713 BC에서 294276 AD까지가 되어 버립니다. 같은 컴파일 옵션으로,time및interval치를 부동 소수점수(실수)로서 저장할까 8바이트 정수로서 저장할지도 정해집니다. 부동 소수점수(실수)의 경우, 큰interval에서는 간격이 증가할 때에 정밀도가 떨어집니다.
time형으로 8바이트 정수가 사용되었을 경우에는, p 는 0에서 6까지의 범위에서 사용 가능합니다. 또, 부동 소수점이 사용되는 경우에는 0에서 10까지가 사용 가능합니다.
time with time zone는 표준 SQL로 정의되고 있습니다만, 그 정의는, 그 유용성을 의문시하게 될 수도 있는 특성을 나타내고 있습니다. 대부분의 경우,date,time,timestamp without time zone,timestamp with time zone의 편성으로, 모든 어플리케이션으로 요구되는 날짜/시각 기능 모두를 제공하고 있을 것입니다.
abstime와reltime는 정밀도의 낮은 데이터형으로, 내부에서 사용되고 있습니다. 새로운 어플리케이션에는 이러한 형태의 사용을 피해 또 적당한 때에 낡은 어플리케이션도 갱신해 주세요. 이러한 내부용의 형태의 일부 또는 모두가 향후의 릴리스에서는 삭제될 가능성이 있습니다.
일자와 시각의 입력은, ISO 8601,SQL호환, 전통적인POSTGRES, 그 외를 포함한 대부분의 적정으로 간주해지는 서식을 받아들입니다. 일자의 입력에 있어서의 달과 날의 순서와 같은 머지않아라고도 해석되는 몇개의 서식에 대해서는, 그러한 필드를 좋아하는 순서로 지정할 수 있게 되어 있습니다. DateStyle파라미터를MDY로 설정하면, 세월년이라고 하는 순서로 해석되어DMY로 설정하면 세월년이라고 하는 순서로,YMD로 설정하면 연월일이라고 하는 순서로 해석됩니다.
PostgreSQL는 일자/시각의 운용에 대해 표준SQL의 요구보다 유연합니다. 일자/시각의 입력에 있어서의 정확한 구문 분석 규칙과 달 및 주, 그리고 시간대를 포함한 사용 가능한 텍스트 필드에 관해서는Appendix B을 참조해 주세요.
텍스트 캐릭터 라인과 같이, 일자나 시각 리터럴은 단일 인용부호로 둘러쌀 필요가 있는 것을 생각해 내 주세요. 자세한 것은Section 4.1.2.5을 참조해 주세요. SQL에서는 아래와 같은 구문이 필요합니다.
type [ ( p ) ] ' value '
여기서, 옵션의 정밀도의 지정 p 는 초 필드의 소수점 이하의 자리수에 대응하는 정수입니다. 정밀도는time,timestamp, 및interval형에 대해서 설정할 수 있습니다. 값의 허용 범위는 이미 설명하고 있습니다. 정수 지정에 대해 정밀도 지정이 없는 경우는, 디폴트의 리터럴치의 정밀도가 됩니다.
Table 8-10는date형으로 입력 가능하지만 일부를 나타냅니다.
Table 8-10. 날짜 입력
| 예 | 설명 |
|---|---|
| January 8, 1999 | 모든datestyle입력 모드에 대해 애매함이 없습니다. |
| 1999-01-08 | ISO 8601. 모든 모드로 1월 8일이 됩니다(추천 서식). |
| 1/8/1999 | MDY모드에서는 1월 8일,DMY모드에서는 8월 1일. |
| 1/18/1999 | MDY모드에서는 1월 18일, 다른 모드에서는 거절됩니다. |
| 01/02/03 | MDY모드에서는 2003년 1월 2일,DMY모드에서는 2003년 2월 1일,YMD모드에서는 2001년 2월 3일. |
| 1999-Jan-08 | 모든 모드로 1월 8일이 됩니다. |
| Jan-08-1999 | 모든 모드로 1월 8일이 됩니다. |
| 08-Jan-1999 | 모든 모드로 1월 8일이 됩니다. |
| 99-Jan-08 | YMD모드로 1월 8일, 다른 모드에서는 에러. |
| 08-Jan-99 | 1월 8일. 다만YMD모드에서는 에러. |
| Jan-08-99 | 1월 8일. 다만YMD모드에서는 에러. |
| 19990108 | ISO 8601. 모든 모드로 1월 8일이 됩니다. |
| 990108 | ISO 8601. 모든 모드로 1월 8일이 됩니다. |
| 1999.008 | 해와 그 날까지의 누계 |
| J2451187 | 율리우스일 |
| January 8, 99 BC | 서기 기원 전 99년 |
The time-of-day types are time [ ( p ) ] without time zone and time [ ( p ) ] with time zone. Writing just time is equivalent to time without time zone.
Valid input for these types consists of a time of day followed by an optional time zone. (See Table 8-11 and Table 8-12.) If a time zone is specified in the input for time without time zone, it is silently ignored. You can also specify a date but it will be ignored, except when you use a time zone name that involves a daylight-savings rule, such as America/New_York. In this case specifying the date is required in order to determine whether standard or daylight-savings time applies. The appropriate time zone offset is recorded in the time with time zone value.
Table 8-11. 시각 입력
| 예 | 설명 |
|---|---|
| 04:05:06. 789 | ISO 8601 |
| 04:05:06 | ISO 8601 |
| 04:05 | ISO 8601 |
| 040506 | ISO 8601 |
| 04:05 AM | 04:05(와)과 같다. AM는 값에 영향을 주지 않습니다. |
| 04:05 PM | 16:05(와)과 같다. 때의 입력은 12 이하가 아니면 안됩니다. |
| 04:05:06. 789-8 | ISO 8601 |
| 04:05:06-08:00 | ISO 8601 |
| 04:05-08:00 | ISO 8601 |
| 040506-08 | ISO 8601 |
| 04:05:06 PST | 생략형에 의한 시간대의 지정. |
| 2003-04-12 04:05:06 America/New_York | 이름에 의한 시간대의 지정. |
Table 8-12. 시간대 입력
| 예 | 설명 |
|---|---|
| PST | 생략형(미국 태평양 표준시간) |
| America/New_York | 완전한 시간대명 |
| PST8PDT | POSIX스타일로 시간대 지정 |
| -8:00 | ISO 8601. PST용의 오프셋(offset) |
| -800 | ISO 8601. PST용의 오프셋(offset) |
| -8 | ISO 8601. PST용의 오프셋(offset) |
| zulu | UTC용의 군사용 약기 |
| z | zulu의 약기 |
시간대의 지정 방법에 관한 자세한 것은 Section 8.5.3을 참조해 주세요.
타임 스탬프형에의 유효한 입력은, 일자와 시각을 세트로 한 것, 게다가 그 후에 옵션으로 시간대, 그 후에 옵션으로AD혹은BC로부터 됩니다 (그 밖에AD/BC를 시간대의 전에 붙이는 방법도 있습니다만, 이것은 추천 되는 순서가 아닙니다). 따라서,
1999-01-08 04:05:06
그리고
1999-01-08 04:05:06 -8:00
유효한 값으로,ISO 8601에 준거하고 있습니다. 또, 넓게 사용되고 있다
January 8 04:05:06 1999 PST
그렇다고 하는 서식도 서포트됩니다.
표준SQL에서는,timestamp without time zone의 리터럴과timestamp with time zone의 리터럴을"+"혹은"-"의 유무로 구별하고 있습니다. 그 때문에, 표준에 따르면,
TIMESTAMP '2004-10-19 10:23:54'
는timestamp without time zone에,
TIMESTAMP '2004-10-19 10:23:54+02'
는timestamp with time zone가 됩니다. PostgreSQL는, 그 형태가 정해지기 전에 캐릭터 라인 리터럴의 내용을 검증하지 않습니다. 그 때문에 위와 같게timestamp without time zone를 취급합니다. 리터럴이 확실히timestamp with time zone로서 다루어지도록 하려면 , 예를 들면,
TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'
와 같이 올바른 명시적인 형태를 지정해 주세요. timestamp without time zone와 결정 끝난 리터럴에서는,PostgreSQL는 경고 없고 시간대 정보를 모두 무시합니다. 즉, 결과의 값은 명시된 입력치의 일자/시각 필드로부터 갖고 오게 됩니다만, 시간대의 조정은 이루어지지 않습니다.
timestamp with time zone에 대해 내부에 저장되고 있는 값은 항상 UTC입니다(협정 세계시, 역사적으로 그리니지 표준시GMT로서 알려져 있습니다). 시간대가 명시적으로 지정된 입력치는, 그 시간대에 적절한 오프셋(offset)를 사용해 UTC에 변환됩니다. 입력 캐릭터 라인에 시간대가 지정되어 있지 않은 경우는, 시스템의timezone파라미터에 나타나고 있는 값이 시간대로 간주해져timezone시간대용의 오프셋(offset)를 사용해 UTC에 변환됩니다.
timestamp with time zone치가 출력되면, 이 값은 UTC로부터 현행의timezone에 변환되어 그 시간대의 로컬 시간으로서 표시됩니다. 다른 시간대에서의 시간을 표시하려면 ,timezone를 변경하든가, 혹은AT TIME ZONE구문을 사용합니다(Section 9.9.3 를 참조).
timestamp without time zone와timestamp with time zone간의 변환에서는, 보통timestamp without time zone치는timezone로컬 시간으로서 보인다, 또는, 지정되는 것과 상정됩니다. AT TIME ZONE를 사용하는 변환에서는, 다른 시간대 참조를 지정할 수 있습니다.
interval의 값은 이하의 구문으로 쓸 수가 있습니다.
[@] quantity unit [ quantity unit ...] [ direction ]
여기서,quantity는(부호 첨부) 시간량,unit(단위)는microsecond,millisecond,second(초),minute(분 ),hour(때),day(일),week(주),month(월),year(해),decade(10년 단위),century(100년 단위),millennium(1000년 단위) 혹은 이러한 단위의 간략형 또는 복수형입니다. direction(방향)는ago혹은 하늘입니다. @ 부호(@)는 옵션으로, 붙여도 붙이지 않아도 상관하지 않습니다. 다른 단위에 있어서의 시간량은 적절히 부호를 고려해 암묵적으로 더해집니다.
일, 시, 분, 및 초의 시간량은 명시적으로 단위를 지정하지 않아도 상관하지 않습니다. 예를 들면,'1 12:59:10'는'1일과 12시간 59분 10초'라고 해석됩니다.
초이하의 옵션의 정밀도 p 는 0에서 6까지의 범위에서, 디폴트는 입력 리터럴의 정밀도입니다.
내부적으로는,interval의 값은 월수, 날짜 및 초 수라고 해 저장되고 있습니다. 어느 달의 날짜는 달에 의해 바뀌고, 서머타임이 도입되고 있으면 1일이 23시간이거나 25시간이거나 하기 때문입니다. 시간 간격은 보통 정수열, 혹은timestamp로부터의 뺄셈으로 생성되기 때문에, 이와 같게 보존하면 대부분의 경우 잘 되어갑니다. justify_days와justify_hours함수로 보통의 범위를 넘은 날과 시각을 조정할 수 있습니다.
PostgreSQL에서는 편리성을 위해서,Table 8-13에 나타나고 있는 것 같은 특별한 날짜/시각 입력치를 서포트하고 있습니다. infinity와-infinity의 값은, 특별히 시스템 내부에서 표현되어 똑같이 표시됩니다. 다른 것은, 단지 간략화된 표기로, 읽히려면 보통의 날짜/시각치에 변환됩니다 (특히now와 그 관련 캐릭터 라인은 읽히자마자 그 시점의 값에 변환됩니다). 이러한 값은 모두, SQL 커멘드로 정수로서 사용하는 경우는, 단일 인용부호로 괄등 없으면 안됩니다.
Table 8-13. 특별한 날짜/시각 정수
| 입력 문자열 | 유효한 형태 | 설명 |
|---|---|---|
| epoch | date, timestamp | 1970-01-01 00:00:00+00(Unix 시스템 시간에 있어서의 제로) |
| infinity | timestamp | 다른 모든 타임 스탬프보다 늦다 |
| -infinity | timestamp | 다른 모든 타임 스탬프보다 빠르다 |
| now | date, time, timestamp | 현트랜잭션(transaction)의 개시시각 |
| today | date, timestamp | 오늘의 시작 |
| tomorrow | date, timestamp | 내일의 시작 |
| yesterday | date, timestamp | 어제의 시작 |
| allballs | time | 00:00:00. 00 UTC |
SQL호환의 함수인,CURRENT_DATE,CURRENT_TIME,CURRENT_TIMESTAMP,LOCALTIME,LOCALTIMESTAMP도, 대응하는 데이터형의 일자 또는 시간의 값으로 해서 사용할 수 있습니다. 후의 4개에서는, 옵션으로서 초이하의 정밀도 지정이 가능합니다 (Section 9.9.4 를 참조해 주세요). 그러나, 이것들은 SQL 함수이며, 데이터 입력 캐릭터 라인으로서는 인식 되지 않는 것으로 주의해 주세요.
날짜/시각형의 출력 서식은,SET datestyle커멘드를 사용해, ISO 8601,SQL(Ingres), 전통적인 POSTGRES, German의 어느 쪽인가에 설정할 수가 있습니다. 디폴트는ISO서식입니다(표준SQL에서는 ISO 8601 서식의 사용이 정해져 있습니다. "SQL"출력 서식명은 우연한 것입니다). Table 8-14에 각 출력 서식의 예를 나타냅니다. date와time의 서식은, 말할 필요도 없이 나타난 예의 각각 일자와 시각의 부분이 됩니다.
Table 8-14. 날짜/시각 출력 형식
| 양식 사양 | 설명 | 예 |
|---|---|---|
| ISO | ISO 8601/표준 SQL | 1997-12-17 07:37:16-08 |
| SQL | 전통적인 양식 | 12/17/1997 07:37:16.00 PST |
| POSTGRES | 특유의 양식 | Wed Dec 17 07:37:16 1997 PST |
| German | 지역 한정 양식 | 17.12.1997 07:37:16.00 PST |
SQL와 POSTGRES에서는, DMY 필드순서가 지정되었을 경우는 달의 전에 날이 나타납니다. 지정이 없으면 날의 전에 달이 나타납니다 (이 설정이 입력치의 해석에 어떻게 영향을 주는지에 대해서는Section 8.5.1을 참고로 해 주세요). Table 8-15에 예를 나타냅니다.
Table 8-15. 일자의 순서의 관습
| datestyle의 설정 | 입력의 순서 | 출력예 |
|---|---|---|
| SQL, DMY | day (일)/ month (월)/ year (해) | 17/12/1997 15:37:16. 00 CET |
| SQL, MDY | month (월)/ day (일)/ year (해) | 12/17/1997 07:37:16. 00 PST |
| Postgres, DMY | day (일)/ month (월)/ year (해) | Wed 17 Dec 07:37:16 1997 PST |
interval의 출력은century나week라고 하는 단위가 해와 날에 변환되는 점과ago가 적절한 부호에 변환되는 점을 제외해, 입력 서식과 같이 표현됩니다. ISO 모드에서의 출력은 이하와 같이 됩니다.
[ quantity unit [ ... ] ] [ days ] [ hours : minutes : seconds ]
유저는SET DATESTYLE커멘드,postgresql.conf구성 파일의DateStyle파라미터, 그리고 서버나 클라이언트의PGDATESTYLE환경 변수를 사용해, 날짜시각의 양식을 선택할 수가 있습니다.
날짜/시각 출력의 것보다 유연한 서식 설정 방법법으로서 서식 설정 함수to_char(Section 9.8를 참조)를 사용할 수도 있습니다.
시간대 및 시간대의 결정은 지구의 기하학적 요소 뿐만 아니라 정치적 판단에 영향을 받습니다. 세계에 걸치는 시간대는 1900년대에 표준화 된 것 같습니다만, 특히 서머타임 규칙의 점으로써, 마음대로 변경하는 경향이 계속되고 있습니다. PostgreSQL는 현재, (전통적인 Unix 시스템 시간의 범위에 일치한다) 1902년부터 2038년까지의 기간에 대해 서머타임 규칙을 서포트합니다. 범위외의 날짜/시각은 선택된 시간대의"표준시간"에 나타내진 것으로 간주합니다.
PostgreSQL는 범용적으로 사용할 수 있도록 표준SQL에의 호환성에 대해 최대한의 노력을 하고 있습니다. 그러나, 표준SQL에는, 일자와 시각의 데이터형과 기능에 관한 혼란이 보여집니다. 2개의 분명한 문제점을 이하에 나타냅니다.
date형에는 거기에 관련하는 시간대가 없습니다만,time형에는 있습니다. 현실의 세계에 있어, 시간대의 오프셋(offset)가 서머타임에의 변환에 의해 연간을 통해서 변화하는 것으로부터, 시각과 같게 일자도 거기에 연결시킬 수 있지 않았다고 의미가 없습니다.
디폴트의 시간대는UTC로부터의 정수 정수 오프셋(offset)로서 지정되고 있습니다. 따라서DST(서머타임)에의 변환을 또 있고로 날짜/시각 연산을 실시하는 경우, 썸머타임을 적용할 수 없습니다.
이러한 문제를 해결하기 위해서는, 시간대를 사용할 때에 일자와 시각의 양쪽 모두를 보관 유지할 수 있는 날짜/시각 데이터형을 사용하는 것을 권합니다. time with time zone형의 사용은 추천 하지 않습니다 (가장PostgreSQL에서는, 구식의 어플리케이션이나, 표준SQL와의 호환성을 위해서,time with time zone형의 사용을 서포트하고 있습니다). PostgreSQL는, 일자 또는 시각만을 보관 유지하는 데이터형의 모두는 사용중의 시간대이라고 전제 하고 있습니다.
모든 시간대 첨부의 일자와 시각은UTC로 내부적으로 보존됩니다. 이것들은 클라이언트에 표시되기 전으로timezone설정 파라미터로 지정된 시간대에 있어서의 로컬 시간에 변환됩니다.
PostgreSQL에서는, 3개의 형식에서 시간대를 지정할 수가 있습니다.
America/New_York등이 완전한 시간대 명칭. 인식할 수 있는 시간대 명칭은pg_timezone_names뷰에 열거되고 있습니다(Section 43.49를 참조해 주세요). PostgreSQL는 이 목적을 위해서 자주 사용되고 있는zic시간대 데이터를 사용합니다. 따라서, 많은 다른 소프트웨어에서도 같은 이름이 인식됩니다.
PST등의 시간대 생략형. 이러한 지정은, 단지 특정의 UTC로부터의 오프셋(offset)를 정의합니다. 한편 완전한 시간대 명칭에서는 서머타임 천이 규칙군도 짜넣어지고 있을 가능성이 있습니다. 인식 가능한 생략형은pg_timezone_abbrevs뷰에 열거되고 있습니다(Section 43.48를 참조해 주세요). 시간대 생략형을 사용해timezone설정 파라미터를 설정할 수 없습니다만, 일자/시각형의 입력치나AT TIME ZONE연산자에 생략형을 사용할 수가 있습니다.
시간대명이나 그 생략형에 가세해PostgreSQL는, STD offset 나 STD offset DST 라고 하는 형식의 POSIX 양식의 시간대 지정을 접수합니다. 여기서, STD 는 시간대 생략형, offset 는 UTC로부터 서쪽으로 센 시간 단위의 오프셋(offset)입니다. 또, DST 는 생략 가능해 서머타임 시간대의 생략형으로, 지정 오프셋(offset)로부터 1시간 진행되는 것을 의미합니다. 예를 들어,EST5EDT가 인식 끝난 시간대명이 아닌 경우에서도, 접수되어 USA 서해안 시간과 같은 것으로서 동작합니다. 서머타임 시간대명이 있으면,zic시간대 데이터베이스의posixrules항목으로 사용되는 서머타임 변환 규칙과 같은 규칙에 따라 사용되는 것과 전제 됩니다. 표준적인PostgreSQLInstallation에서는,posixrules은US/Eastern와 같습니다. 이 때문에 POSIX 서식의 시간대 지정은 USA 서머타임 규칙에 따릅니다. 필요에 따라서posixrules파일을 옮겨놓는 것으로, 이 동작을 조정할 수가 있습니다.
생략형과 생략 없음의 명칭의 사이에는 개념적 및 실질적인 차이가 있습니다. 생략형은 UTC로부터 고정한 오프셋(offset)를 나타내는데 대해, 대부분의 생략 없음의 명칭은 로컬의 서머타임 규정을 의미하므로, UTC 오프셋(offset)에는 2개의 가능성이 있습니다.
시간대 생략계의 정당성을 검사하지 않기 때문에, POSIX 서식 시간대 기능에서는 이상한 입력을 경고 없게 받아들여 버릴 가능성이 있는 것에 주의해야 합니다. 예를 들면, 시스템의 동작은 보다 독특한 UTC의 생략계를 계속 사용한 상태로,SET TIMEZONE TO FOOBAR0에서도 동작합니다.
모든 경우에 대해, 시간대명은 대문자 소문자의 구별 없게 인식됩니다. (이것은PostgreSQL의 버젼 8.2 이전부터의 변경으로, 모두가 아닙니다만, 어느 문맥에서는 대문자 소문자가 구별되었습니다. )
생략 이루어, 생략형의 어느쪽이나 서버내에 짜넣어지는 것은 아닙니다. 인스톨 디렉토리의,.../share/timezone/ 및 .../share/timezonesets/아래에 보존되는 구성 파일로부터 취득됩니다(Section B.3를 참조해 주십시오).
timezone는postgresql.conf파일가게Chapter 17에서 설명하는 다른 표준적인 방법으로 설정할 수가 있습니다. 이하에, 몇개인가 특별한 설정 방법법을 나타냅니다.
postgresql.conf내나 서버의 커멘드 라인 스윗치로timezone가 지정되어 있지 않은 경우, 디폴트의 시간대로서TZ환경 변수의 값을 사용하려고 시도합니다. TZ가 정의되어 있지 않은 경우나TZ가PostgreSQL로 인식 가능한 시간대 명칭이 아니었던 경우, 서버는,localtime()C라이브러리 함수의 동작을 검사하는 것으로 operating system의 디폴트의 시간대를 결정하려고 시도합니다. 이 디폴트의 시간대는,PostgreSQL가 인식 가능한 시간대중에서 가장 가까운 것이 선택됩니다.
SET TIME ZONE SQL커멘드는 세션의 시간대를 설정합니다. 이것은 SQL 사양 호환의 문법에 의해 따라서 있는SET TIMEZONE TO의 별명입니다.
클라이언트에 의해PGTZ환경 변수가 설정되어 있는 경우, 접속 확립시에 서버에 대해SET TIME ZONE커멘드를libpq어플리케이션이 송신합니다.
PostgreSQL는 모든 일자와 시각의 계산에 유리우스일을 사용하고 있습니다. 이것은, 기원 전 4,713년부터 미래까지의 모든 일자를, 1년은 365.2425일이라고 가정해 정확한 예측이나 계산을 한다고 하는 뛰어난 특성을 가지고 있습니다.
19 세기 이전의 일자 규칙은 재미있는 읽을 거리로는 됩니다만, 날짜/시각 핸들러의 올바른 코딩을 보증하는 것은 정합성에 대해 완벽하지는 않습니다.