標準SQLでは、「「日付時刻リテラル」定義の中で、「日付時刻の値」はグレゴリオ暦に従った日付と時間の自然法則に則る」と明記されています。PostgreSQLは標準SQLの指針に従い、グレゴリオ暦が使われる以前の年に対してもグレゴリオ暦で日付を数えます。この規則は先発グレゴリオ暦として知られています。Caesar)によって広められたものです。西欧でグレゴリオ暦への移行が開始された1582年まで一般的に使用されていました。ユリウス暦では、太陽年は365日+1/4日=365.25日と概算されます。この暦では、128年で約1日のずれが生じます。Trent)の勧告に従って累積していた暦のずれを修正しました。グレゴリオ暦では、太陽年は365+97/400日=365.2425日と近似されます。したがって、グレゴリオ暦で太陽年が1日ずれるにはおよそ3,300年を要します。365+97/400という近似は、下記の規則に従って400年間に97回のうるう年を設けることによって得られています。4で割り切れる年を、うるう年にする。100で割り切れる年は、うるう年にしない。400で割り切れる年は、結局うるう年とする。したがって、1700、1800、1900、2100、2200はうるう年ではありませんが、2000、2400はうるう年です。それに比べ、古いユリウス暦では4で割り切れる年のみがうるう年でした。1582年2月の教皇勅書は、1582年の10月から10日間除外することを命じ、したがって10月4日の翌日を10月15日としました。この慣行はイタリア、ポーランド、ポルトガル、スペインで遵守されました。他のカトリックの国々もすぐ後に追従しましたが、プロテスタントの国々は変更を嫌がり、ギリシャ正教を信奉する国々は20世紀の初めまで変更を行いませんでした。1752年に大英帝国とその自治領(現在のアメリカ合衆国を含む)でもその改革は行われました。したがって、1752年9月2日の次は1752年9月14日となっています。このような理由から、Unixシステムでcalプログラムを実行すると、下記のような結果になります。30しかし、当然、この暦は大英帝国とその自治領でのみ有効なものであり、他の場所ではそうではありません。様々な場所で様々な時代に使われていた実際の暦を追いかけることは難しく、また、混乱することになるでしょうから、PostgreSQLは追いかけることはせず、この方法が歴史的に正確でなくても日付すべてでグレゴリオ暦の規則に従います。グレゴリオ暦が開発されるより前から、様々な暦が世界の多くの地域で開発されました。中国暦のルーツは紀元前14世紀まで遡ることができますし、伝説では、黄帝が紀元前2637年にこの暦を発明したとされています。中華人民共和国では、公的な目的ではグレゴリオ暦を使用していますが、祝祭日の決定には中国暦を使用します。ユリウス日は別の種類の暦であり、名前が似ていて混乱しますが、ユリウス暦とは関係ありません。Scaliger(1484-1558)からの引用と考えられます。0(よくいわゆるユリウス日と呼ばれます)から始まる日は連番です。0はユリウス暦の紀元前4713年1月1日、またはグレゴリオ暦の紀元前4714年11月24日に対応します。ユリウス日の数え方は、天文学者が夜間の観測にラベルを付けるためにより良く使用されました。このため、深夜0時から深夜0時までではなく、UTC正午から次のUTC正午までが1日でした。0は紀元前4714年11月24日のUTC正午から紀元前4714年11月25日のUTC正午までの24時間であると明示されています。PostgreSQLは日付の入出力においてユリウス日記法を(および、一部の日付時間間隔の計算においてユリウス日を)サポートしますが、正午から正午までという微妙な日付の数え方を守っていません。PostgreSQLは深夜0時から深夜0時までとしてユリウス日を扱います。