Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.
Postgres must have 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.
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 common time zones defined
in the United States, CST and EST.
If the compiler option USE_AUSTRALIAN_RULES is set
then CST and EST will be
interpreted using Australian conventions.
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.
Tip: 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 v7.0 the rules have
been tightened up to reduce the possibility of ambiguity.
