1
<!-- doc/src/sgml/datetime.sgml -->
3
<appendix id="datetime-appendix">
4
<title>Date/Time Support</title>
7
<productname>PostgreSQL</productname> uses an internal heuristic
8
parser for all date/time input support. Dates and times are input as
9
strings, and are broken up into distinct fields with a preliminary
10
determination of what kind of information can be in the
11
field. Each field is interpreted and either assigned a numeric
12
value, ignored, or rejected.
13
The parser contains internal lookup tables for all textual fields,
14
including months, days of the week, and time zones.
18
This appendix includes information on the content of these
19
lookup tables and describes the steps used by the parser to decode
23
<sect1 id="datetime-input-rules">
24
<title>Date/Time Input Interpretation</title>
27
The date/time type inputs are all decoded using the following procedure.
33
Break the input string into tokens and categorize each token as
34
a string, time, time zone, or number.
40
If the numeric token contains a colon (<literal>:</>), this is
41
a time string. Include all subsequent digits and colons.
47
If the numeric token contains a dash (<literal>-</>), slash
48
(<literal>/</>), or two or more dots (<literal>.</>), this is
49
a date string which might have a text month. If a date token has
50
already been seen, it is instead interpreted as a time zone
51
name (e.g., <literal>America/New_York</>).
57
If the token is numeric only, then it is either a single field
58
or an ISO 8601 concatenated date (e.g.,
59
<literal>19990113</literal> for January 13, 1999) or time
60
(e.g., <literal>141516</literal> for 14:15:16).
66
If the token starts with a plus (<literal>+</>) or minus
67
(<literal>-</>), then it is either a numeric time zone or a special
76
If the token is a text string, match up with possible strings:
82
Do a binary-search table lookup for the token as a time zone
89
If not found, do a similar binary-search table lookup to match
90
the token as either a special string (e.g., <literal>today</literal>),
91
day (e.g., <literal>Thursday</literal>),
92
month (e.g., <literal>January</literal>),
93
or noise word (e.g., <literal>at</literal>, <literal>on</literal>).
99
If still not found, throw an error.
107
When the token is a number or number field:
113
If there are eight or six digits,
114
and if no other date fields have been previously read, then interpret
115
as a <quote>concatenated date</quote> (e.g.,
116
<literal>19990118</literal> or <literal>990118</literal>).
117
The interpretation is <literal>YYYYMMDD</> or <literal>YYMMDD</>.
123
If the token is three digits
124
and a year has already been read, then interpret as day of year.
130
If four or six digits and a year has already been read, then
131
interpret as a time (<literal>HHMM</> or <literal>HHMMSS</>).
137
If three or more digits and no date fields have yet been found,
138
interpret as a year (this forces yy-mm-dd ordering of the remaining
145
Otherwise the date field ordering is assumed to follow the
146
<varname>DateStyle</> setting: mm-dd-yy, dd-mm-yy, or yy-mm-dd.
147
Throw an error if a month or day field is found to be out of range.
155
If BC has been specified, negate the year and add one for
156
internal storage. (There is no year zero in the Gregorian
157
calendar, so numerically 1 BC becomes year zero.)
163
If BC was not specified, and if the year field was two digits in length,
164
then adjust the year to four digits. If the field is less than 70, then
165
add 2000, otherwise add 1900.
169
Gregorian years AD 1-99 can be entered by using 4 digits with leading
170
zeros (e.g., <literal>0099</> is AD 99).
179
<sect1 id="datetime-keywords">
180
<title>Date/Time Key Words</title>
183
<xref linkend="datetime-month-table"> shows the tokens that are
184
recognized as names of months.
187
<table id="datetime-month-table">
188
<title>Month Names</title>
193
<entry>Abbreviations</entry>
198
<entry>January</entry>
202
<entry>February</entry>
226
<entry>August</entry>
230
<entry>September</entry>
231
<entry>Sep, Sept</entry>
234
<entry>October</entry>
238
<entry>November</entry>
242
<entry>December</entry>
250
<xref linkend="datetime-dow-table"> shows the tokens that are
251
recognized as names of days of the week.
254
<table id="datetime-dow-table">
255
<title>Day of the Week Names</title>
260
<entry>Abbreviations</entry>
265
<entry>Sunday</entry>
269
<entry>Monday</entry>
273
<entry>Tuesday</entry>
274
<entry>Tue, Tues</entry>
277
<entry>Wednesday</entry>
278
<entry>Wed, Weds</entry>
281
<entry>Thursday</entry>
282
<entry>Thu, Thur, Thurs</entry>
285
<entry>Friday</entry>
289
<entry>Saturday</entry>
297
<xref linkend="datetime-mod-table"> shows the tokens that serve
298
various modifier purposes.
301
<table id="datetime-mod-table">
302
<title>Date/Time Field Modifiers</title>
306
<entry>Identifier</entry>
307
<entry>Description</entry>
312
<entry><literal>AM</literal></entry>
313
<entry>Time is before 12:00</entry>
316
<entry><literal>AT</literal></entry>
317
<entry>Ignored</entry>
320
<entry><literal>JULIAN</>, <literal>JD</>, <literal>J</></entry>
321
<entry>Next field is Julian Day</entry>
324
<entry><literal>ON</literal></entry>
325
<entry>Ignored</entry>
328
<entry><literal>PM</literal></entry>
329
<entry>Time is on or after 12:00</entry>
332
<entry><literal>T</literal></entry>
333
<entry>Next field is time</entry>
340
<sect1 id="datetime-config-files">
341
<title>Date/Time Configuration Files</title>
344
<primary>time zone</primary>
345
<secondary>input abbreviations</secondary>
349
Since timezone abbreviations are not well standardized,
350
<productname>PostgreSQL</productname> provides a means to customize
351
the set of abbreviations accepted by the server. The
352
<xref linkend="guc-timezone-abbreviations"> run-time parameter
353
determines the active set of abbreviations. While this parameter
354
can be altered by any database user, the possible values for it
355
are under the control of the database administrator — they
356
are in fact names of configuration files stored in
357
<filename>.../share/timezonesets/</> of the installation directory.
358
By adding or altering files in that directory, the administrator
359
can set local policy for timezone abbreviations.
363
<varname>timezone_abbreviations</> can be set to any file name
364
found in <filename>.../share/timezonesets/</>, if the file's name
365
is entirely alphabetic. (The prohibition against non-alphabetic
366
characters in <varname>timezone_abbreviations</> prevents reading
367
files outside the intended directory, as well as reading editor
368
backup files and other extraneous files.)
372
A timezone abbreviation file can contain blank lines and comments
373
beginning with <literal>#</>. Non-comment lines must have one of
377
<replaceable>time_zone_name</replaceable> <replaceable>offset</replaceable>
378
<replaceable>time_zone_name</replaceable> <replaceable>offset</replaceable> D
379
@INCLUDE <replaceable>file_name</replaceable>
385
A <replaceable>time_zone_name</replaceable> is just the abbreviation
386
being defined. The <replaceable>offset</replaceable> is the zone's
387
offset in seconds from UTC, positive being east from Greenwich and
388
negative being west. For example, -18000 would be five hours west
389
of Greenwich, or North American east coast standard time. <literal>D</>
390
indicates that the zone name represents local daylight-savings time
391
rather than standard time. Since all known time zone offsets are on
392
15 minute boundaries, the number of seconds has to be a multiple of 900.
396
The <literal>@INCLUDE</> syntax allows inclusion of another file in the
397
<filename>.../share/timezonesets/</> directory. Inclusion can be nested,
402
The <literal>@OVERRIDE</> syntax indicates that subsequent entries in the
403
file can override previous entries (i.e., entries obtained from included
404
files). Without this, conflicting definitions of the same timezone
405
abbreviation are considered an error.
409
In an unmodified installation, the file <filename>Default</> contains
410
all the non-conflicting time zone abbreviations for most of the world.
411
Additional files <filename>Australia</> and <filename>India</> are
412
provided for those regions: these files first include the
413
<literal>Default</> file and then add or modify timezones as needed.
417
For reference purposes, a standard installation also contains files
418
<filename>Africa.txt</>, <filename>America.txt</>, etc, containing
419
information about every time zone abbreviation known to be in use
420
according to the <literal>zoneinfo</> timezone database. The zone name
421
definitions found in these files can be copied and pasted into a custom
422
configuration file as needed. Note that these files cannot be directly
423
referenced as <varname>timezone_abbreviations</> settings, because of
424
the dot embedded in their names.
429
If an error occurs while reading the time zone data sets, no new value is
430
applied but the old set is kept. If the error occurs while starting the
431
database, startup fails.
437
Time zone abbreviations defined in the configuration file override
438
non-timezone meanings built into <productname>PostgreSQL</productname>.
439
For example, the <filename>Australia</> configuration file defines
440
<literal>SAT</> (for South Australian Standard Time). When this
441
file is active, <literal>SAT</> will not be recognized as an abbreviation
448
If you modify files in <filename>.../share/timezonesets/</>,
449
it is up to you to make backups — a normal database dump
450
will not include this directory.
456
<sect1 id="datetime-units-history">
457
<title>History of Units</title>
460
The Julian calendar was introduced by Julius Caesar in 45 BC.
461
It was in common use in the Western world
462
until the year 1582, when countries started changing to the Gregorian
463
calendar. In the Julian calendar, the tropical year is
464
approximated as 365 1/4 days = 365.25 days. This gives an error of
465
about 1 day in 128 years.
469
The accumulating calendar error prompted
470
Pope Gregory XIII to reform the calendar in accordance with
471
instructions from the Council of Trent.
472
In the Gregorian calendar, the tropical year is approximated as
473
365 + 97 / 400 days = 365.2425 days. Thus it takes approximately 3300
474
years for the tropical year to shift one day with respect to the
479
The approximation 365+97/400 is achieved by having 97 leap years
480
every 400 years, using the following rules:
484
Every year divisible by 4 is a leap year.
487
However, every year divisible by 100 is not a leap year.
490
However, every year divisible by 400 is a leap year after all.
494
So, 1700, 1800, 1900, 2100, and 2200 are not leap years. But 1600,
495
2000, and 2400 are leap years.
497
By contrast, in the older Julian calendar all years divisible by 4 are leap
502
The papal bull of February 1582 decreed that 10 days should be dropped
503
from October 1582 so that 15 October should follow immediately after
505
This was observed in Italy, Poland, Portugal, and Spain. Other Catholic
506
countries followed shortly after, but Protestant countries were
507
reluctant to change, and the Greek Orthodox countries didn't change
508
until the start of the 20th century.
510
The reform was observed by Great Britain and Dominions (including what is
511
now the USA) in 1752.
512
Thus 2 September 1752 was followed by 14 September 1752.
514
This is why Unix systems have the <command>cal</command> program
515
produce the following:
518
$ <userinput>cal 9 1752</userinput>
528
The SQL standard states that <quote>Within the definition of a
529
<quote>datetime literal</quote>, the <quote>datetime
530
value</quote>s are constrained by the natural rules for dates and
531
times according to the Gregorian calendar</quote>. Dates between
532
1582-10-05 and 1582-10-14, although eliminated in some countries
533
by Papal fiat, conform to <quote>natural rules</quote> and are
534
hence valid dates. <productname>PostgreSQL</> follows the SQL
535
standard's lead by counting dates exclusively in the Gregorian
536
calendar, even for years before that calendar was in use.
540
Different calendars have been developed in various parts of the
541
world, many predating the Gregorian system.
544
the beginnings of the Chinese calendar can be traced back to the 14th
545
century BC. Legend has it that the Emperor Huangdi invented that
548
The People's Republic of China uses the Gregorian calendar
549
for civil purposes. The Chinese calendar is used for determining
554
The <quote>Julian Date</quote> is unrelated to the <quote>Julian
556
The Julian Date system was invented by the French scholar
557
Joseph Justus Scaliger (1540-1609)
558
and probably takes its name from Scaliger's father,
559
the Italian scholar Julius Caesar Scaliger (1484-1558).
560
In the Julian Date system, each day has a sequential number, starting
561
from JD 0 (which is sometimes called <emphasis>the</> Julian Date).
562
JD 0 corresponds to 1 January 4713 BC in the Julian calendar, or
563
24 November 4714 BC in the Gregorian calendar. Julian Date counting
564
is most often used by astronomers for labeling their nightly observations,
565
and therefore a date runs from noon UTC to the next noon UTC, rather than
566
from midnight to midnight: JD 0 designates the 24 hours from noon UTC on
567
1 January 4713 BC to noon UTC on 2 January 4713 BC.
571
Although <productname>PostgreSQL</> supports Julian Date notation for
572
input and output of dates (and also uses them for some internal datetime
573
calculations), it does not observe the nicety of having dates run from
574
noon to noon. <productname>PostgreSQL</> treats a Julian Date as running
575
from midnight to midnight.