Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit92df220

Browse files
committed
Improve documentation around historical calendar rules.
Get rid of section 8.5.6 (Date/Time Internals), which appears to confusepeople more than it helps, and anyway discussion of Postgres' internaldatetime calculation methods seems pretty out of place here. Instead,make datatype.sgml just say that we follow the Gregorian calendar (a bitof specification not previously present anywhere in that chapter :-()and link to the History of Units appendix for more info. Do some mildeditorialization on that appendix, too, to make it clearer that we arefollowing proleptic Gregorian calendar rules rather than anything morehistorically accurate.Per a question from Florence Cousin and subsequent discussion inpgsql-docs.
1 parent7c85aa3 commit92df220

File tree

2 files changed

+40
-39
lines changed

2 files changed

+40
-39
lines changed

‎doc/src/sgml/datatype.sgml‎

Lines changed: 4 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1511,6 +1511,9 @@ SELECT E'\\xDEADBEEF';
15111511
linkend="datatype-datetime-table">. The operations available
15121512
on these data types are described in
15131513
<xref linkend="functions-datetime">.
1514+
Dates are counted according to the Gregorian calendar, even in
1515+
years before that calendar was introduced (see <xref
1516+
linkend="datetime-units-history"> for more information).
15141517
</para>
15151518

15161519
<table id="datatype-datetime-table">
@@ -1804,7 +1807,7 @@ MINUTE TO SECOND
18041807
</row>
18051808
<row>
18061809
<entry>J2451187</entry>
1807-
<entry>Julianday</entry>
1810+
<entry>Juliandate</entry>
18081811
</row>
18091812
<row>
18101813
<entry>January 8, 99 BC</entry>
@@ -2757,23 +2760,6 @@ P <optional> <replaceable>years</>-<replaceable>months</>-<replaceable>days</> <
27572760

27582761
</sect2>
27592762

2760-
<sect2 id="datatype-datetime-internals">
2761-
<title>Internals</title>
2762-
2763-
<para>
2764-
<productname>PostgreSQL</productname> uses Julian dates
2765-
for all date/time calculations. This has the useful property of correctly
2766-
calculating dates from 4713 BC
2767-
to far into the future, using the assumption that the length of the
2768-
year is 365.2425 days.
2769-
</para>
2770-
2771-
<para>
2772-
Date conventions before the 19th century make for interesting reading,
2773-
but are not consistent enough to warrant coding into a date/time handler.
2774-
</para>
2775-
</sect2>
2776-
27772763
</sect1>
27782764

27792765
<sect1 id="datatype-boolean">

‎doc/src/sgml/datetime.sgml‎

Lines changed: 36 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -318,7 +318,7 @@
318318
</row>
319319
<row>
320320
<entry><literal>JULIAN</>, <literal>JD</>, <literal>J</></entry>
321-
<entry>Next field is JulianDay</entry>
321+
<entry>Next field is JulianDate</entry>
322322
</row>
323323
<row>
324324
<entry><literal>ON</literal></entry>
@@ -456,6 +456,24 @@
456456
<sect1 id="datetime-units-history">
457457
<title>History of Units</title>
458458

459+
<indexterm zone="datetime-units-history">
460+
<primary>Gregorian calendar</primary>
461+
</indexterm>
462+
<indexterm zone="datetime-units-history">
463+
<primary>Julian date</primary>
464+
</indexterm>
465+
466+
<para>
467+
The SQL standard states that <quote>Within the definition of a
468+
<quote>datetime literal</quote>, the <quote>datetime
469+
values</quote> are constrained by the natural rules for dates and
470+
times according to the Gregorian calendar</quote>.
471+
<productname>PostgreSQL</> follows the SQL
472+
standard's lead by counting dates exclusively in the Gregorian
473+
calendar, even for years before that calendar was in use.
474+
This rule is known as the <firstterm>proleptic Gregorian calendar</>.
475+
</para>
476+
459477
<para>
460478
The Julian calendar was introduced by Julius Caesar in 45 BC.
461479
It was in common use in the Western world
@@ -507,8 +525,8 @@
507525
reluctant to change, and the Greek Orthodox countries didn't change
508526
until the start of the 20th century.
509527

510-
The reform was observed by Great Britain andDominions(including what is
511-
now the USA) in 1752.
528+
The reform was observed by Great Britain andits dominions(including what
529+
isnow the USA) in 1752.
512530
Thus 2 September 1752 was followed by 14 September 1752.
513531

514532
This is why Unix systems have the <command>cal</command> program
@@ -522,18 +540,14 @@ $ <userinput>cal 9 1752</userinput>
522540
17 18 19 20 21 22 23
523541
24 25 26 27 28 29 30
524542
</screen>
525-
</para>
526543

527-
<para>
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.
544+
But, of course, this calendar is only valid for Great Britain and
545+
dominions, not other places.
546+
Since it would be difficult and confusing to try to track the actual
547+
calendars that were in use in various places at various times,
548+
<productname>PostgreSQL</> does not try, but rather follows the Gregorian
549+
calendar rules for all dates, even though this method is not historically
550+
accurate.
537551
</para>
538552

539553
<para>
@@ -551,8 +565,9 @@ $ <userinput>cal 9 1752</userinput>
551565
</para>
552566

553567
<para>
554-
The <quote>Julian Date</quote> is unrelated to the <quote>Julian
555-
calendar</quote>.
568+
The <firstterm>Julian Date</firstterm> system is another type of
569+
calendar, unrelated to the Julian calendar though it is confusingly
570+
named similarly to that calendar.
556571
The Julian Date system was invented by the French scholar
557572
Joseph Justus Scaliger (1540-1609)
558573
and probably takes its name from Scaliger's father,
@@ -564,15 +579,15 @@ $ <userinput>cal 9 1752</userinput>
564579
is most often used by astronomers for labeling their nightly observations,
565580
and therefore a date runs from noon UTC to the next noon UTC, rather than
566581
from midnight to midnight: JD 0 designates the 24 hours from noon UTC on
567-
1 January 4713 BC to noon UTC on2 January 4713 BC.
582+
24 November 4714 BC to noon UTC on25 November 4714 BC.
568583
</para>
569584

570585
<para>
571586
Although <productname>PostgreSQL</> supports Julian Date notation for
572-
input and output of dates (and also usesthemfor 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.
587+
input and output of dates (and also usesJulian datesfor some internal
588+
datetimecalculations), it does not observe the nicety of having dates
589+
run fromnoon to noon. <productname>PostgreSQL</> treats a Julian Date
590+
as runningfrom midnight to midnight.
576591
</para>
577592

578593
</sect1>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp