Date/Time Support
Time Zones
time zones
Postgres contains internal tabular
information for time zone decoding, since there is no *nix standard
system interface to provide access to general, cross-timezone
information. The underlying OS is used to
provide time zone information for output, however.
Postgres Recognized Time Zones
Time Zones
Time Zone
Offset from UTC
Description
NZDT
+13:00
New Zealand Daylight Time
IDLE
+12:00
International Date Line, East
NZST
+12:00
New Zealand Standard Time
NZT
+12:00
New Zealand Time
AESST
+11:00
Australia Eastern Summer Standard Time
ACSST
+10:30
Central Australia Summer Standard Time
CADT
+10:30
Central Australia Daylight Savings Time
SADT
+10:30
South Australian Daylight Time
AEST
+10:00
Australia Eastern Standard Time
EAST
+10:00
East Australian Standard Time
GST
+10:00
Guam Standard Time, USSR Zone 9
LIGT
+10:00
Melbourne, Australia
ACST
+09:30
Central Australia Standard Time
SAST
+09:30
South Australia Standard Time
CAST
+09:30
Central Australia Standard Time
AWSST
+9:00
Australia Western Summer Standard Time
JST
+9:00
Japan Standard Time,USSR Zone 8
KST
+9:00
Korea Standard Time
WDT
+9:00
West Australian Daylight Time
MT
+8:30
Moluccas Time
AWST
+8:00
Australia Western Standard Time
CCT
+8:00
China Coastal Time
WADT
+8:00
West Australian Daylight Time
WST
+8:00
West Australian Standard Time
JT
+7:30
Java Time
WAST
+7:00
West Australian Standard Time
IT
+3:30
Iran Time
BT
+3:00
Baghdad Time
EETDST
+3:00
Eastern Europe Daylight Savings Time
CETDST
+2:00
Central European Daylight Savings Time
EET
+2:00
Eastern Europe, USSR Zone 1
FWT
+2:00
French Winter Time
IST
+2:00
Israel Standard Time
MEST
+2:00
Middle Europe Summer Time
METDST
+2:00
Middle Europe Daylight Time
SST
+2:00
Swedish Summer Time
BST
+1:00
British Summer Time
CET
+1:00
Central European Time
DNT
+1:00
Dansk Normal Tid
FST
+1:00
French Summer Time
MET
+1:00
Middle Europe Time
MEWT
+1:00
Middle Europe Winter Time
MEZ
+1:00
Middle Europe Zone
NOR
+1:00
Norway Standard Time
SET
+1:00
Seychelles Time
SWT
+1:00
Swedish Winter Time
WETDST
+1:00
Western Europe Daylight Savings Time
GMT
0:00
Greenwich Mean Time
WET
0:00
Western Europe
WAT
-1:00
West Africa Time
NDT
-2:30
Newfoundland Daylight Time
ADT
-03:00
Atlantic Daylight Time
NFT
-3:30
Newfoundland Standard Time
NST
-3:30
Newfoundland Standard Time
AST
-4:00
Atlantic Standard Time (Canada)
EDT
-4:00
Eastern Daylight Time
CDT
-5:00
Central Daylight Time
EST
-5:00
Eastern Standard Time
CST
-6:00
Central Standard Time
MDT
-6:00
Mountain Daylight Time
MST
-7:00
Mountain Standard Time
PDT
-7:00
Pacific Daylight Time
PST
-8:00
Pacific Standard Time
YDT
-8:00
Yukon Daylight Time
HDT
-9:00
Hawaii/Alaska Daylight Time
YST
-9:00
Yukon Standard Time
AHST
-10:00
Alaska-Hawaii Standard Time
CAT
-10:00
Central Alaska Time
NT
-11:00
Nome Time
IDLW
-12:00
International Date Line, West
Australian Time Zones
Australian time zones and their naming variants
account for fully one quarter of all time zones in the
Postgres time zone lookup table.
There are two naming conflicts with time zones commonly used
in the United States, CST and EST.
If the runtime option AUSTRALIAN_TIMEZONES is set
then CST, EST, and
SAT will be
interpreted as Australian timezone names. Without this option,
CST and EST are taken as
American timezone names, while SAT is interpreted as a
noise word indicating Saturday.
Postgres Australian Time Zones
Australian Time Zones
Time Zone
Offset from UTC
Description
CST
+10:30
Australian Central Standard Time
EST
+10:00
Australian Eastern Standard Time
SAT
+9:30
South Australian Standard Time
Date/Time Input Interpretation
The date/time types are all decoded using a common set of routines.
Date/Time Input Interpretation
Break the input string into tokens and categorize each token as
a string, time, time zone, or number.
If the token contains a colon (":"), this is a time string.
If the token contains a dash ("-"), slash ("/"), or dot ("."),
this is a date string which may have a text month.
If the token is numeric only, then it is either a single field
or an ISO-8601 concatenated date (e.g. 19990113 for January 13, 1999)
or time (e.g. 141516 for 14:15:16).
If the token starts with a plus ("+") or minus ("-"),
then it is either a time zone or a special field.
If the token is a text string, match up with possible strings.
Do a binary-search table lookup for the token
as either a special string (e.g. today),
day (e.g. Thursday),
month (e.g. January),
or noise word (e.g. on).
Set field values and bit mask for fields.
For example, set year, month, day for today,
and additionally hour, minute, second for now.
If not found, do a similar binary-search table lookup to match
the token with a time zone.
If not found, throw an error.
The token is a number or number field.
If there are more than 4 digits,
and if no other date fields have been previously read, then interpret
as a concatenated date
(e.g. 19990118). 8
and 6 digits are interpreted as year, month, and day, while 7
and 5 digits are interpreted as year, day of year, respectively.
If the token is three digits
and a year has already been decoded, then interpret as day of year.
If four or more digits, then interpret as a year.
If in European date mode, and if the day field has not yet been read,
and if the value is less than or equal to 31, then interpret as a day.
If the month field has not yet been read,
and if the value is less than or equal to 12, then interpret as a month.
If the day field has not yet been read,
and if the value is less than or equal to 31, then interpret as a day.
If two digits or four or more digits, then interpret as a year.
Otherwise, throw an error.
If BC has been specified, negate the year and offset by one for
internal storage
(there is no year zero in the Gregorian calendar, so numerically
1BC becomes year zero).
If BC was not specified, and if the year field was two digits in length, then
adjust the year to 4 digits. If the field was less than 70, then add 2000;
otherwise, add 1900.
Gregorian years 1-99AD may be entered by using 4 digits with leading
zeros (e.g. 0099 is 99AD). Previous versions of
Postgres accepted years with three
digits and with single digits, but as of version 7.0 the rules have
been tightened up to reduce the possibility of ambiguity.
History of Units
Contributed by José Soares (jose@sferacarta.com)
The Julian Day was invented by the French scholar
Joseph Justus Scaliger (1540-1609)
and probably takes its name from the Scaliger's father,
the Italian scholar Julius Caesar Scaliger (1484-1558).
Astronomers have used the Julian period to assign a unique number to
every day since 1 January 4713 BC. This is the so-called Julian Day
(JD). JD 0 designates the 24 hours from noon UTC on 1 January 4713 BC
to noon UTC on 2 January 4713 BC.
Julian Day
is different from Julian Date
.
The Julian calendar was introduced by Julius Caesar in 45 BC. It was
in common use until the 1582, when countries started changing to the
Gregorian calendar.
In the Julian calendar, the tropical year is approximated as 365 1/4
days = 365.25 days. This gives an error of about 1 day in
128 years.
The accumulating calendar error prompted Pope Gregory XIII
to reform the calendar in accordance with instructions
from the Council of Trent.
In the Gregorian calendar, the tropical year is approximated as
365 + 97 / 400 days = 365.2425 days. Thus it takes approximately 3300
years for the tropical year to shift one day with respect to the
Gregorian calendar.
The approximation 365+97/400 is achieved by having 97 leap years
every 400 years, using the following rules:
Every year divisible by 4 is a leap year.
However, every year divisible by 100 is not a leap year.
However, every year divisible by 400 is a leap year after all.
So, 1700, 1800, 1900, 2100, and 2200 are not leap years. But 1600,
2000, and 2400 are leap years.
By contrast, in the older Julian calendar only years divisible by 4 are leap years.
The papal bull of February 1582 decreed that 10 days should be dropped
from October 1582 so that 15 October should follow immediately after
4 October.
This was observed in Italy, Poland, Portugal, and Spain. Other Catholic
countries followed shortly after, but Protestant countries were
reluctant to change, and the Greek orthodox countries didn't change
until the start of this century.
The reform was observed by Great Britain and Dominions (including what is
now the USA) in 1752.
Thus 2 Sep 1752 was followed by 14 Sep 1752.
This is why Unix systems have cal
produce the following:
% cal 9 1752
September 1752
S M Tu W Th F S
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
SQL92 states that
Within the definition of a datetime literal,
the datetime values are constrained by the
natural rules for dates and times
according to the Gregorian calendar
.
Dates between 1752-09-03 and 1752-09-13, although eliminated in
some countries by Papal fiat, conform to
natural rules
and are hence valid dates.
Different calendars have been developed in various parts of the
world, many predating the Gregorian system.
For example,
the beginnings of the Chinese calendar can be traced back to the 14th
century BC. Legend has it that the Emperor Huangdi invented the
calendar in 2637 BC.
The People's Republic of China uses the Gregorian calendar
for civil purposes. Chinese calendar is used for determining
festivals.