Postgresの0001年のタイムゾーンに、UTCからのこのようなクレイジーなオフセットがあるのはなぜですか?


16

Postgres 9.5では、年0001(ゼロ0000年なし)を試しているときに以下の結果が表示されたことに驚きました。

のオフセット-07:52:58

いくつかのサンプルコード。Iの混合使用することを注意TIMESTAMP WITH TIME ZONEしてTIMESTAMP WITHOUT TIME ZONE、慎重に読んでください。

SET TIME ZONE 'America/Los_Angeles' ;

SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0', 
        TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z', 
        TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z') ;

("2015-01-01 00:00:00-08","0001-12-31 16:07:02-07:52:58 BC","0001-01-01 00:00:00")

私はその2番目の値に驚いています0001-12-31 16:07:02-07:52:58 BCAmerica/Los_AngelesUTCから8時間遅れているのと同じように、オフセットを8時間戻し-08:00ます。しかし-08:00、オフセットの代わりにです-07:52:58。どうして?

UTCで問題なし

UTCでデータを入力する場合、このような問題はありません。

SET TIME ZONE 'UTC' ;

SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0',  
        TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z', 
        TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z');

("2015-01-01 00:00:00+00","0001-01-01 00:00:00+00","0001-01-01 00:00:00")

年ゼロなし

ちなみに、日付部分は正しいようです。0000「BC」時代と「AD」時代の要点である年はないようです。年0001の最初の瞬間をとって1時間を差し引くと、年が得られます0001 BCので、年のゼロはありません。

SET TIME ZONE 'UTC' ;

INSERT INTO moment_  -- TIMESTAMP WITH TIME ZONE.
VALUES ( TIMESTAMP '0001-01-01 00:00:00.0Z' - INTERVAL '1 hour' ) ;

SET TIME ZONE 'UTC' ;

TABLE moment_ ;

結果は年な0001 BCので、からにジャンプ00010001 BCます。年ゼロはありません0000

"0001-12-31 23:00:00+00 BC"


BCとADの間のピボットポイントは1年目です。1年目または1年目です。それは、元々年がどのように命名されているかだけです。0年目は存在しません(むしろ、存在的というよりも定義の問題であるため未定義です)。
スリーブマン16

2000年のお祝いの際に、一部の教訓的な人々が、2000年ではなく2001年に技術的に第2千年紀が始まると言ったときのことを思い出してください。それが理由です。年は0ではなく1から始まります。また、1年前の年は紀元前1年(つまり、
slebetman

1
使用中のカレンダーに依存する@slebetman。予後グレゴリオ暦には、1 CEの前の年として0を使用する形式と、1 CEの直前に1 BCEを配置する形式の両方があります(ISO 8601は0000、有効な年の値として両方をサポートしますが、使用するかどうかを主張しません) )。PostgreSQLが年0のない形式を使用しているのは事実ですが、「万年が0ではなく1から始まる」とは、その普遍的な事実のようなものではありません。たとえば天文データの場合、それらの間の変換は簡単です。(3番目の千年紀は、西暦1年以来3番目の千年紀のままであるため、どちらの方法でも2001年に開始されました)
ジョンハンナ

@JonHanna:誰も実際に使用していなかった任意の -年間ゼロを持っていない私は特権にここにユリウス暦をそれの公正だと思うので、かかわらず、一度に先発グレゴリオ暦の形を。
ケビン

回答:


22

1883年11月18日12:00(新しい時間)に、アメリカの鉄道で標準時間が採用されました。

これは、その時間の前に、ロサンゼルスは平均太陽時間に基づいて実際の現地時間を使用したことを意味します。その後、ローカルタイムゾーンに移動しました。これは、グリニッジ標準時からの時間の整数オフセットであり、前回とはわずかに異なりました。

もっと知りたい?

  • IANA:Timeゾーンからtzdata Timezone Databaseをダウンロードします

  • 内部には、(多くの)タイムゾーンの定義があります。これには、時間の経過とともに多くのバリエーションがあり、変更が行われた場所と時期を詳述する多くのコメントがあります。楽しい読書です!

  • ウィキペディアには、Wikipedia:Time zoneページで、1883年11月18日の変更に関する興味深い事実もあります。

鉄道の時間
...
19世紀半ばのアメリカの鉄道の計時はやや混乱していました。各鉄道は、通常、本社または最も重要な終点の現地時間に基づいて、独自の標準時間を使用し、鉄道の列車のスケジュールは独自の時間を使用して公開されました。いくつかの鉄道が運行するいくつかのジャンクションには、各鉄道の時計があり、それぞれ異なる時刻を示していました。
...ダウドのシステムは、アメリカの鉄道では決して受け入れられませんでした。代わりに、米国とカナダの鉄道は、旅行者の公式鉄道ガイドの編集者であるウィリアムF.アレンによって提案されたバージョンを実装しました。そのタイムゾーンの境界は、多くの場合主要都市にある鉄道駅を通りました。たとえば、東部時間帯と中部時間帯の境界は、デトロイト、バッファロー、ピッツバーグ、アトランタ、チャールストンを通過しました。1883年11月18日(日曜日)に発足し、正午の日」とも呼ばれ、各タイムゾーン内で標準時間の正午に達すると各鉄道駅の時計がリセットされました。ゾーンは、植民地間、東部、中央、山、太平洋と名付けられました。...

また、これはPostgresqlに固有のものではないことに注意してください。これは、tzdataデータベースを使用するすべてのソフトウェアまたはオペレーティングシステムで有効です(もちろん、多くは1970年以降または1901年以降の日付に制限されるため、1883年には到達できませんが、他にも多くの調整があります。異なる時間)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.