日付とは？
|
日付変更線はこの項目国際日付変更線へ転送されています。広瀬香美のシングルについては日付変更線 (広瀬香美)をご覧ください。 国際日付変更線（こくさいひづけへんこうせん、International date line）は、日付の更新の矛盾を防ぐために海上に設けられたほぼ東経180度（西経180度）の地点を結ぶ架空の線。単に日付変更線ともいう。 経度で15度違う地域では、1時間時刻が異なる。旅行者が、15度移動するたびに時計の針を1時間ずつずらしていくと、世界一周したとき、時刻は正しいが日付が1日異なることになる。これを防ぐため、西から東にこれをまたぐ場合、日付を1日戻し、東から西にまたぐときに日付を1日増やす。 このため、国際日付変更線をまたいだとたん、前日に戻ったり、計算上一瞬で24時間後になったりする。実際、オセアニアの航空路線の中には、実際のフライト時間としては6時間未満なのに日付が2日後になったり、逆に前日にカレンダーを戻したりするものも少なくない（たとえばエア・カナダのシドニー発ホノルル行き航空便は、到着地で日付を前日に戻す）。 国際日付変更線は海上に設定され、隣の町や村で日付が変わるなどの不便がないようにしている。 また、この線はどこかの機関が制定、届出、認可をしているものではなく、日付変更線付近に存在する国や地域が国内法で定めるものにすぎない[1]。 例えば日本で誕生日を祝ったあと、すぐに飛行機でハワイに飛ぶ。すると、まだ前日なので、日付が変わってからもう1回誕生日を祝ったりする。 かつてはキリバス共和国の領土上を通過していたが、1995年にこれを是正した。これにより、現在最も早く日付が変わる国はキリバスとなっている。 マゼランの世界一周の航海のときに、この日付の矛盾が発覚した。乗組員がスペインに降り立ったとき、彼らが記録していた日付とスペインの日付が1日ずれていた。そして、乗組員たちは、自分たちの日付が正しいと主張した。このときには大騒ぎになり、ローマ教皇のところに使者が出される事態にまで発展した。 この矛盾は現在では容易に説明がつく。つまり、マゼラン一行は地球の自転とは逆向きに世界を1周したのだから、地球が自転した回数よりも彼らが地球のまわりを回転した回数が1周少ないはずである。つまり、彼らが見た日の出の回数は、スペインにとどまっていた人々が見た回数より1回少なくなる。 もし、一行が逆の向きで世界一周をしたならば、一行は地球の自転の回数に加え、さらにもう1回回転してしまったわけだから、日付は1日減らさなければ他の人々と日付が合わない。 日付変更線をうまく利用した小説が、ジュール・ヴェルヌの『八十日間世界一周』である。この物語の中で、80日で世界一周ができるかどうかの賭けが行われた。途中トラブルがあり、予定より1日遅く、81日目に主人公たちは世界一周の旅を終えて戻った。しかし、実際の日付は80日後だった。これは国際日付変更線がまだ一般的でなかった時代に、これをトリックとして使ったものである。 |
[ 60] 国際日付変更線 - Wikipedia
[引用サイト] http://ja.wikipedia.org/wiki/%E5%9B%BD%E9%9A%9B%E6%97%A5%E4%BB%98%E5%A4%89%E6%9B%B4%E7%B7%9A
|
確定日付とは、文字通り、変更のできない確定した日付のことであり、その日にその証書（文書）が存在していたことを証明するものです。公証役場で付与される確定日付とは、公証人が私書証書に日付のある印章（確定日付印）を押捺した場合のその日付をいいます。 文書は、その作成日付が重要な意味を持つことが少なくありません。したがって、金銭消費貸借契約等の法律行為に関する文書や覚書等の特定の事実を証明する文書等が作成者等のいろいろな思惑から、その文書の作成の日付を実際の作成日より遡らせたりして、紛争になることがあります。確定日付は、このような紛争の発生をあらかじめ防止する効果があります。また、指名債権の譲渡の通知又は承諾は、確定日付のある証書をもってしなければ、債務者以外の第三者に対抗することができません（民法４６７条２項）。指名債権を目的とする債権質も、同様に、第三債務者に対する通知又はその承諾について，確定日付のある証書をもってしなければ、第三債務者その他の第三者に対抗することができません（民法３６４条）。そこで、このような文書には、公証人による確定日付を付しておくことが必要となります。 確定日付の付与は、文書に公証人の確定日付印を押捺することにより、その文書の押捺の日付を確定し、その文書がその確定日付を押捺した日に存在することを証明するものです。文書の成立や内容の真実性についてはなんら公証するものではありません。この点、文書の内容である法律行為等記載された事項を公証する「公正証書」や、文書等の署名押印などが真実になされたことを公証する「認証」とは異なります。 官公署又は官公吏がその権限に基づき作成する文書は、その日付が確定日付となりますので、公証人は確定日付を付することはできません。 例えば、不動産登記簿謄本は、公務員である登記官がその権限に基づいて作成するものですから、その謄本に記載された作成日付が確定日付となり、公証人はこれに確定日付を付することはできません。 私文書は、文字その他の記号により、意見、観念または思想的意味を表示しているものであることが必要です。 図面または写真は，それ自体としては、意見、観念等を表示しているとはいえませんので、それ自体に確定日付を付することはできません。しかし、例えば、写真を台紙に貼って割印し、台紙に撮影の日時，場所等のデータを記入した証明文を記載して記名押印する方法で私署証書とした場合には、これに確定日付を付与することができます。 文書のコピー自体には、確定日付を付与することはできません。そのコピー上に写しを作成した旨付記するか、または、同様の説明文言を表示する証書を添付するなどして割り印し、それらの説明文書に確定日付を付与することになります。 内容の違法な文書、無効な法律行為を記載した文書であることが明らかなものは、確定日付を付与することはできません。 作成年月日の記載を欠いたものは、公証人が確定日付を付与した後にその作成年月日を補充することにより混乱が生ずるのを防止するため、作成年月日欄に棒線を引いてもらうか、空欄である旨付記した上で確定日付を付与する取り扱いにしています。 後日の記入を前提とするような、形式上未完成な文書は、そのままでは確定日付を付与することはできません。 記名はあるが押印を欠くもの、押印はあるが作成者名称を欠くものは補充を求めたうえ、確定日付を付与する取り扱いをしています。 署名又は記名は、氏名をフルネームで記載する必要はなく、氏又は名のみでもよく、通称、商号、雅号、仮名でも差し支えありません。 確定日付の付与は、公証役場に対し請求し、公証人がその文書に日付ある印章を押捺して付与します。確定日付の年月日は請求当日の年月日となります。 付与の請求は作成者自身でする必要はなく、代理人又は使者によってすることもできます。この場合でも、委任状等や印鑑証明書等の提出は不要で、運転免許証等の提示も必要ありません。 |
[ 61] 確定日付
[引用サイト] http://www.koshonin.gr.jp/ka.html
|
日付の表記方法は、文化的な背景の違い、また用途の違いによって様々なフォーマットがあります。多くの場合、特に断り無く使っても問題なく正しい日時を伝えることができますが、文脈や利用者の環境によっては、意外な落とし穴にはまることもあります。誤解なく、かつ効率的に処理しやすい日時表記方法としては、2001-08-02T10:35Zというスタイルの、ISO/W3Cフォーマットがあります。 よく見かける日付の表記法として、01/08/02という具合に2桁の年月日をスラッシュで区切ってつないだものがあります。これはなかなか曲者で、地域によって意味が全く違うのです。 こうした違いを認識していないと、使用する文脈によっては思わぬ誤解を生じる危険があります。明らかに日本人（あるいはイギリスの人、アメリカの人）しか読まないという文書でなければ、この表記法を用いるのはあまり賢明とはいえません。 年を4桁にすると、日本式と欧米式は区別できるはずですが、ヨーロッパとアメリカはやはり区別が不可能です。また、音声ブラウザ（例：IBMホームページリーダー）は、01/08/02という記述があると、 こういう混乱を避け、日時を一意に表記できるようにするために、国際標準化機構（ISO）においてISO 8601:1988[ISO8601]（翻訳版がJIS X 0301-1992）が定められました。ただ、この標準はかなり多くのバリエーションを定義している上、西暦年の上2桁の省略を認めているため、あまり使い勝手が良くありません。そこで、IS0 8601のサブセットとして、日時の表記方法を限定し、よりシンプルにしたものがW3Cからノート[W3CDTF]として公開されました。 W3Cのノートで示されている表記法はW3C-DTF（もしくはW3CDTF）と呼ばれ[*注]、次の6通りのフォーマットがあります。 上記のフォーマットで変数として表記しているアルファベットは、一般に使われるようにYMDがそれぞれ年月日、hmsがそれぞれ時分秒を表す数字を意味します。小数点以下の秒を表記するばあい、桁数に制限はありません。TZDはタイムゾーンを示す部分で、UTC（協定世界時＝グリニッジ標準時）との時差を+09:00などとして示すか、UTCで表記していることを示す Z を記述します。また、年月日と時分秒はアルファベットの T で区切ります。 この表記法は曖昧さなく、かつコンパクトに日時を示すことができ、またソフトウェアでの処理も簡単であるというメリットがあります。[HTML4]では、%Datetime;（ins/del要素タイプのdatetime属性）は、このW3C-DTFの(5)の形式を用いるようセクション6.11で示しています（WebSiteDesignに掲載した記事の「修正日時の書式」を参照）。 XML Schemaのデータ型[XSDTYPE]では、W3C-DTFの年月日時分秒をフルに表すフォーマット(5)(6)がdateTime型として定義されています。ただし、W3C-DTFではタイムゾーンが必須なのに対し、dateTime型ではオプション扱いです。 その他の型として、年月日だけを示す YYYY-MM-DD（ISO8601:1988やXML Schemaでは年を CCYY と表記）はdate型、年だけを示す YYYY はgYear型、年月を示す YYYY-MM はgYearMonth型、また時分秒のみを示す hh:mm:ss はtime型など、細かいデータ型が定義されています。9999年を超えた場合は、年の左に桁を追加して良いということも定められています（ISO 8601も2000年の第2版では年の拡張を認めています）。 インターネットの電子メールなどのプロトコルで日時のタイムスタンプを示すためのフォーマットは、次のセクションで示すように伝統的な書式がありますが、今後登場する新しいプロトコルはISO 8601に基づいた新しいフォーマットを用いることが[RFC3339]で示されました。この規格では、XML SchemaのdateTime型と同様に、W3C-DTFの(5)およびオプションとして(6)の書式が標準として採用されています。また、読みやすさなどの観点から、日付フォーマットと時刻フォーマットを空白で連結する 2001-08-02 10:45:23+09:00 という記述も認められます。 日本ではしばしばピリオドで年月日を区切った「2001.08.02」という書式が使われます。このピリオド区切りの日付は、ドイツやロシアなどヨーロッパの一部では"02.08.2001" (DD.MM.YYYY)という形式でよく使われるようです（DB2や一部のSQLではこの日付書式をEUR＝欧州標準規格と呼んでいます）。一方、スイスやノルウェイでは MM.DD.YYYY という書式が以前使われたりしたようで、/ 区切りと同様の混乱を招く可能性はあります *（デンマークでは、手紙などの日付に MM/DD-YYYY という混合書式が使われるという話も見かけました。国によってはDD-MM-YYYYというのもあるらしいです）。 〔*注〕 スイスやノルウェイの日付表記は、FreeDOSの付属文書の国コードに関する説明で拾った情報ですが、裏付けがとれないのでいったん削除します。 ピリオド区切り書式は、ISO 8601には定められていませんが、JIS X 0301では元号を表記する書式として追加されています。 YYYY.MM.DD の形式は、情報交換用としてはスタンダードとはいえないので、できればW3C-DTFを用いる方が応用範囲が広がるでしょう。 電子メールやHTTPヘッダでは、曜日を持ち、月を3文字のアルファベットで示す日付表記が用いられます。[RFC2822]で定められているのは、次のような書式です。 HTTP/1.1[RFC2616]では、歴史的な経緯により多少異なる書式も認められていますが、RFC 2822のフォーマットに従うのが一般的です。 UNIXのdateコマンドや、Javascriptなどでは、C言語のctime()関数のフォーマットに準じて、一般に次のような出力がデフォルトになっています。 これらの書式は、長い間用いられているので、それなりに処理ルーチンも整備されてはいますが、プログラムに扱いやすいフォーマットというわけではありません。データとして処理する可能性のある日付は、やはりW3C-DTFで記述する方が汎用性が高いと思います。今後登場するインターネットプロトコルは、上に記したようにW3C-DTFスタイルでタイムスタンプを記述することになる見込みです。 特定の日付でなく、複数の日にまたがっていることを表記したい場合もあります。フェスティバルが8月2日〜9月10日であるというようなケースで、共通して理解可能なフォーマットを使いたいことがあるかも知れません。 期間表記については、W3Cのフォーマットには含まれていませんが、ISO 8601には次のようにスラッシュ（ / ）を用いる表記方法が定められています。 ISO 8601に従えば、この期間表記の始点と終点で、共通する上位要素は省略できます。この場合、2001年は共通なので次のように表記できます。 あまりポピュラーとは言えない表記である上、音声読み上げではやはり分数のようになってしまうという難点もありますが、試してみる価値はあるでしょう。 メタデータを記述する標準語彙のひとつであるDublin Coreでは、期間を表記するための語彙とその表現方法も定めています[DCPERIOD]。たとえば、フェスティバルの期間をXMLで記述するには次のようにします。 日時のフォーマットはW3C-DTFがデフォルトですが、異なる表記方法を使う場合は、start, end要素にscheme属性でそのフォーマットを指定することになっています。 ここまで述べてきた様々な日付フォーマットは、人間にとって読みやすく誤解がないことと、ソフトウェアで処理しやすいことのバランスを考慮して書式が定められています。機械処理が目的なら、ISO 8601の基本形式（区切り記号を用いるのは拡張形式）による次のような表記が効率が良いでしょう。 人間が読むことを第一に考える場合は、素直に「2001年8月2日」と書くのが一番分かりやすいわけです（特に音声合成を考えると、きちんと年月日という単位を加えるのが恐らくベスト）。あるいは、国際化を意識するなら August 2, 2001 など。人間は文脈を判断できますから、明らかな場合は年表記を略すのもありです（明らかでないのに省略すると、あとから読んだときに時期が不明という、別のよくある落とし穴にはまります）。 データの汎用性という観点からは、例えばMicrosoft Excelにデータを貼り付ける場合、「2001-08-02」「2001/08/02」「2001年8月2日」は日付データとして扱われますが、「2001.08.02」は文字列として扱われる（日本の場合）、といった点も考慮すると良さそうです。 文書内に記述する日付にどの書式を採用するのが望ましいかは、その日付を主として人間が読むのか、ソフトウェアの処理も念頭に置くのかによって異なってきます。本文で地の文として出てくる日付は「2001年8月2日」型がわかりやすいでしょうし、統計などの表を示すならW3C-DTFを用いておくと再利用がしやすくなるでしょう（本文中でも、適切なクラス付けでメタデータを抽出できるようにする場合には、W3C-DTFのほうが良さそう）。日記の日付や文書の更新日を記述する場合は、簡単には決めにくい要素がありますが、相互運用性の高い情報発信のためには、これらもW3C-DTFを用いて書くのが望ましいのかもしれません。 2000年12月に改訂版ISO 8601:2000(E)が発行されています。年を5桁以上に拡張できる規定、閏秒の扱い、繰り返し期間の表記などが加わりました。また年の表記がCCYYからYYYYに変更されるなど、細かい修正が加えられています。 |
[ 62] 日付の表記に関するノート
[引用サイト] http://www.kanzaki.com/docs/html/dtf.html
