stanford-oval/wikipedia huggingface dataset:
Amazon.ae
歴史

ウェブサイトはロナルド・ムーチャウォーといった共同創業者達により2005年に設立された。当初はネットポータル「Maktoob」にリンクしたオークションサイトだった 。2011年にSouqは事業モデルをAmazonと同様のネットショッピングに変更し、マーケットプレイスと小売商品の販売を自社のプラットフォーム上で行った。
2014年3月、Souqは南アフリカのケープタウンに拠点を置くナスパーズから7500万ドルの出資を受け 、Souqが調達した資金のトータル額は1億5000万ドルに達した 。2014年時点でソークが調達した1億5000万ドルは中東のインターネットベースの企業が調達した額としては最大のものである。
同社はタイガー・グローバル・マネジメントとナスパーズの支援を受けていた。2015年時点でドバイに本社を置いている 。2015年10月にSouqは一連の資金調達で、同社は10億ドル相当の価値があると報じられた。当時Souqには毎月1000万人が訪れていた。
2017年3月27日、BBCが「ドバイ最大のモールの運営者」と表現したエマール・モールズがSouqに対し8億ドルの買収提案をした。2017年3月28日、アマゾンは不明額でSouqを買収すると確認した。情報筋がウォール・ストリート・ジャーナル紙に取引は約7億ドルの価値だったと語った 。フィナンシャル・タイムズ紙は取引は「6億5000万ドル以上だったと理解している」と報じた 。BBCはAmazonは約6億5000万ドルを支払うだろうと報じた。取引の完了は2017年の下旬に計画されている。
買収に伴い、Souq.comは現在Amazonの子会社となり、Amazonのアラブ世界部門として機能するようになった。2019年5月、Souq.com UAEはAmazon.aeとなり、同年9月にAmazonはUAEでAmazon DSPを開始し、2020年6月にSouq.com KSAはAmazon.saになった。
2021年9月1日にSouq.com Egyptも「amazon.eg」と名称を変更し、Souq.comのブランド名に公式に終わりを告げた。
概観

2017年3月時点で、Souqは「家電、ファッション、ヘルスとビューティー、家庭用品とベビー用品」を含む31カテゴリー840万種類の製品を販売している 。Souqには毎月約4500万人が訪れる 。2016年時点でアラブ世界で最大の電子商取引プラットフォームであり 、しばしば中東のAmazonと表現されることがある。2014年時点でSouqの配達地域はUAE、サウジアラビア、クウェート、エジプト、バーレーン、オマーン、カタールである。
2017年3月時点で、Souqはサウジアラビア、UAE、エジプトに事業拠点を持ち 、2014年時点で UAE、サウジアラビア、クウェート、エジプトに半自動化された現代のフルフィルメントセンターを持ち、広さは計3万5000平方メートルに及ぶ。当時、同社はエンジニアリング、小売、カスタマーサポート、フルフィルメントセンターとラストマイル配達セクションで約2500人の従業員を雇用している。
Souq.comの子会社

2018年1月時点でのSouq.comの子会社には、配送部門に「QExpress」、決済プラットフォーム「payfort」、修理・サービスマーケットプレイス「Helpbit」、配送マーケットプレイス「Wing」がある。
水野智彦 (実業家)

水野 智彦(みずの ともひこ、1891年2月5日 - 1997年12月11日）は、日本の経営者。日本特殊陶業社長、会長を務めた。東京都出身。
経歴

1915年に慶應義塾大学部理財科を卒業し、同年に森村組に入社。1956年に取締役に就任し、1934年に日本陶器取締役にも就任し、1944年には日本特殊陶業専務に就任し、1949年に取締役、1961年に監査役、1963年に顧問を経て、1971年に社長に就任。1973年に会長に就任。
1972年に勲三等瑞宝章を受章。
1997年12月11日、呼吸不全のために死去。106歳没。
汝州市

| 中華人民共和国 河南省 汝州市 |
| --- | --- |
風穴寺の仏塔群風穴寺の仏塔群
旧称：梁県、臨汝
 河南省中の汝州市の位置河南省中の汝州市の位置
簡体字: 汝州
繁体字: 汝州
拼音: Rǔzhōu
カタカナ転写: ジューチョウ

国家:  中華人民共和国
省: 河南
地級市: 平頂山
行政級別: 県級市






面積
総面積: 1573 km²

人口
総人口(2004): 97 万人








経済




電話番号: 0375
郵便番号: 467500
行政区画代碼: 410482

汝州市（じょしゅう-し）は中華人民共和国河南省に位置する県級市。省直轄市であるが現在は平頂山市が代わりに管轄している。
石炭が豊富に産出し「百里煤海」と称される。そのほかにもボーキサイトなども産出する。また古くから陶磁器で知られており、現在でも製陶業は重要な産業である。風穴寺は河南四大名寺の一つ。
歴史

1988年に臨汝県が県級市に昇格して成立した。
行政区画

街道:煤山街道、風穴路街道、鐘楼街道、洗耳河街道、汝南街道、紫雲路街道
鎮:寄料鎮、温泉鎮、臨汝鎮、小屯鎮、楊楼鎮、蟒川鎮、廟下鎮、米廟鎮、陵頭鎮、紙坊鎮、大峪鎮、夏店鎮、焦村鎮
郷:王寨郷、騎嶺郷
出身者

趙秉鈞 - 清末民初の政治家。袁世凱の腹心で、国務総理をつとめた。
| 典拠管理データベース  |
| --- | --- |
全般:  VIAF 
国立図書館:  イスラエル  アメリカ
ハーバード方式

| --- | --- |
: この項目では、出典の示し方について説明しています。 デーヴァナーガリー文字の代替表記については「京都・ハーバード方式」をご覧ください。  コンピュータ・アーキテクチャについては「ハーバード・アーキテクチャ」をご覧ください。  恒星の分類については「スペクトル分類#ハーバード分類」をご覧ください。
| --- | --- |
: ウィキペディアにおけるハーバード方式については、「Wikipedia:出典を明記する/個別参照法#姓年参照」をご覧ください。
ハーバード方式（ハーバードほうしき、Harvard referencing system）は、論文で引用した出典を、著者の姓と発行年に基づいて示す方法である (科学技術振興機構 2008)。著者名・発行年方式 (author-date referencing system)、挿入方式 (parenthetical referencing system) ともいう。
かつて本文中や各ページの脚注に散在させていた参考文献の書誌を論文末尾にまとめて列挙し、その順序を著者姓と発行年の昇順とし、本文での言及を著者姓と発行年のみで行うことが特徴である (Chernin 1988)。（下例）
ハーバード方式の例
概要

参考文献の書誌事項を、本文に直接書かずに最後に列挙し、本文には参考文献の著者名と発行年のみを記述して出典を示す方法を、ハーバード方式という (科学技術振興機構 2008)。参考文献を列挙する章は、「参考文献」(References) や「文献目録」(Bibliography)、「参照文献」「引用文献」「言及文献」(Works Cited) 等と題され、著者名は通常ファミリーネームが後に書かれる欧米などの人の名前の場合でも、それが先になり、以下のように書かれる。参考文献はその著者の姓のアルファベット順に並べられる(科学技術振興機構 1986, §5.9 (2))。本文では、引用の直後に、参考文献の著者名と発行年を括弧の中に入れて示し、末尾の参考文献を参照する (科学技術振興機構 1986, §5.9 (1))。例えば、(Smith 2005) のような形である。ページ番号も分かる場合は、(Smith 2005 p. 1) や (Smith 2005: 1) のように記述される。したがって、参考文献の章での書誌事項は次のように書かれる。
Smith, John. (2005) , Florida:Wikimedia Foundation. ISBN X-XXXXXX-XX-X.
起源とバリエーション

ハーバード方式を初めて使用したのは、エドワード・ローレンス・マーク（英語版）（Mark (1881)）である。彼は、ハーバード大学の解剖学の教授で動物研究所の所長であり、研究所の図書館の分類方法（図書分類法）を応用した (Chernin 1988)。
ハーバード方式は人文・社会科学以外の科学分野でよく利用されている (University of Georgia 2004, 冒頭文)。美術、歴史、文学分野では、脚注をつける方式である「ドキュメント・ノート法」 ("documentary-note") や「古典文学法」 ("humanities") が伝統的に好まれている。バンクーバー方式(科学技術振興機構 2008)と呼ばれるハーバード方式のバリエーションは、主に医学分野で利用されている。最近では、「大多数の科学技術教育組織」 ("most scholarly and professional organizations") がハーバード方式を採用している。
書誌の書き方とその参照方法

ハーバード方式では、参考文献を論文の末尾にまとめて列挙し、本文からはその著者の苗字と出版年（ページの範囲）でその参考文献を参照する (科学技術振興機構 1986, §5.9)。これは、この項目の冒頭で示した例のような形となる。
ページ番号とページ範囲は、その文献全てが参照される場合には省略される。著者の苗字は記述される文中に表れる場合は、かっこ内では省略される。これは次のような例の場合である。
「ジョーンズは外傷手術分野を改革した（ジョーンズ 2001, pp. 1-999）」→「ジョーンズ（2001）は外科手術分野を改革した」
2 - 3人の著者を参照する場合は、「and」や「&」(アンパサンド)を使用して記述する。例えば (Author, Smith, and Jones 1991)、(Author, Smith & Jones 1991) の形である。4人以上の場合、「～ら」(et al.) を使用して記述する。例として次のようになる。(Author et al. 1992)
出版年が不明の場合、「不明」("n.d.") と記述する (科学技術振興機構 2007, 4.3.4 (3))。例: (Deane n.d.)。重版された参考文献を参照する場合は、角括弧に元の出版年を記述する。例: (Marx [1867] 1967, p. 90)。
もし、参照した複数の文献に、同一著者で同一出版年のものが存在した場合、先に発行されたものから順番にアルファベットの添え字を出版年につける。例: 2005年の場合、最初のものを2005a、2つ目を2005bとする。
参照は引用の直後に挿入するか、その文末の句点の前に置く。ただし、複数の文章にわたって引用を行った場合は、句点の後に置く。
書誌事項は論文の末尾の章に、アルファベット順で列挙する (科学技術振興機構 1986, §5.9 (2))。ただし、技術論文の参照の場合、アルファベット順ではなく、登場順に記述される場合もある（バンクーバー方式） (科学技術振興機構 1986, §5.9 (2))。これらの記載は、「参考文献」 ("References") や「参照文献」 ("Works Cited") に置かれる。文献目録 (biblography) は、本文から参照されていない非言及文献まで含むことがある点で、参照文献 (works cited) や参考文献と異なる (科学技術振興機構 2008)。
参照は本文と同じフォントで記述する。バリエーションとして、使用する分野によりフォントの記述に関してのルールが存在する場合もある（例えば、書名をイタリック体にする、論文誌の号数をボールド体もしくはアンダーラインを使用する等） (科学技術振興機構 2007, 付録: 国際的な参照文献の記述スタイル)。
書誌の書き方とその参照方法 > 書誌の例

本の書誌の例としては、次の形になる。
Smith, J. (2005a). Harvard Referencing, Wherever, Florida:Wikimedia Foundation. ISBN 1-899235-74-4.
Smith, J. (2005b). More Harvard Referencing, Wherever, Florida:Wikimedia Foundation. ISBN 1-899235-74-4.
論文の書誌の例としては、次の形になる。
Smith, John Maynard. (1998). The origin of altruism. Nature 393: 639-40.
新聞記事の書誌の例としては、次の形になる。
Bowcott, O. (October 18, 2005). "Protests halt online auction to shoot stag", Guardian.
もし、記事がオフラインのものである場合、次の形になる。
Bowcott, O. (October 18, 2005). "Protests halt online auction to shoot stag." Guardian.
ハーバード方式を採用した投稿規定としては、アメリカ心理学会のAPAスタイルが挙げられる (科学技術振興機構 2007, 付録 (4))。
ハーバード方式と要旨の記述

ハーバード方式は要旨を記述 ("content notes") するために使用される脚注と互換性がある。ハーバード法は、参考文献の記述（"reference notes"、文章記述式の参考文献）に用いられる。ハーバード法でも要旨を記述するために脚注を利用することもある。
関連文献

Perelman, Leslie; Paradis, James; Barrett, Edward (n.d.), “§10 Citing sources and listing references”, The Mayfield Handbook of Technical and Scientific Writing, http://www.mhhe.com/mayfieldpub/tsw/csxlr.htm 2009年2月22日閲覧, [参考文献の記述方法、科学技術記述法のメイフィールドの手引き 非専門家向けの内容要旨]
2024年パリオリンピックのコンゴ民主共和国選手団

| 0 | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
オリンピックのコンゴ民主共和国選手団

コンゴ民主共和国の国旗
IOCコード：: COD
2024年パリオリンピック
人員:: 選手 6人
旗手:: 開会式 ドミニク・ムランバ ブリジット・ムバビ 閉会式 ブリジット・ムバビ
| メダル  | 金 0 | 銀 0 | 銅 0 | 計 0 |
夏季オリンピックコンゴ民主共和国選手団
1968 • 1972 • 1976 • 1980 • 1984 • 1988 • 1992 • 1996 • 2000 • 2004 • 2008 • 2012 • 2016 • 2020 • 2024 (1984-1996はザイールとして出場)
2024年パリオリンピックのコンゴ民主共和国選手団は、2024年7月26日から8月11日までフランスのパリで開催された2024年パリオリンピックのコンゴ民主共和国選手団の名簿。
選手団

人員: 選手 6人
開会式旗手: ドミニク・ムランバ、ブリジット・ムバビ
閉会式旗手: ブリジット・ムバビ
種目別選手・スタッフ名簿及び成績 > 陸上

| 選手 | 種目 | 予備予選> 結果 | 予備予選> 順位 | 予選> 結果 | 予選> 順位 | 準決勝> 結果 | 準決勝> 順位 | 決勝> 結果 | 決勝> 順位 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| ドミニク・ムランバ | 男子100m | 失格 | 失格 | 予備予選敗退 | 予備予選敗退 | 予備予選敗退 | 予備予選敗退 | 予備予選敗退 | 予備予選敗退 |
種目別選手・スタッフ名簿及び成績 > ボクシング

| 選手 | 種目 | 1回戦 | 2回戦 | 準々決勝 | 準決勝 | 決勝 | 順位 |
| --- | --- | --- | --- | --- | --- | --- | --- |

| マルセラ・サコビ | 女子フェザー級 |  ウズベキスタン トゥルディベコワ L 2-3 | 1回戦敗退 | 1回戦敗退 | 1回戦敗退 | 1回戦敗退 | 1回戦敗退 |

| ブリジット・ムバビ | 女子ウェルター級 | (bye) |  タイ スワンナペン L 1-4 | 2回戦敗退 | 2回戦敗退 | 2回戦敗退 | 2回戦敗退 |
種目別選手・スタッフ名簿及び成績 > 柔道

| 選手 | 種目 | 1回戦 | 2回戦 | 準々決勝 | 準決勝 | 敗者復活戦 | 決勝/3位決定戦 | 順位 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| アルノルド・キソカ | 男子60kg級 |  イスラエル ウォルチャク L 000-101 | 1回戦敗退 | 1回戦敗退 | 1回戦敗退 | 1回戦敗退 | 1回戦敗退 | 1回戦敗退 |
種目別選手・スタッフ名簿及び成績 > 競泳

| 選手 | 種目 | 予選> 結果 | 予選> 順位 | 準決勝> 結果 | 準決勝> 順位 | 決勝> 結果 | 決勝> 順位 |
| --- | --- | --- | --- | --- | --- | --- | --- |

| アリストット・ヌドンベ | 男子50m自由形 | 29秒04 | 70位 | 予選敗退 | 予選敗退 | 予選敗退 | 予選敗退 |

| ディヴィヌ・ミアンサディ | 女子50m自由形 | 44秒10 | 79位 | 予選敗退 | 予選敗退 | 予選敗退 | 予選敗退 |
たしかなこと (曖昧さ回避)

たしかなこと
たしかなこと - 2005年5月25日に発売された小田和正の23rdシングル。
たしかなこと (ウルフルズの曲) - 2007年10月31日に発売されたウルフルズの31stシングル。
Tz database

| --- | --- |
作者:  アーサー・デイヴィッド・オルソン（Arthur David Olson、"ado"）、ポール・エッガート（Paul Eggert）
開発元:  IANA

最新版:  2020e    / 2020年12月23日 (3年前) (2020-12-23)
リポジトリ:  github.com/eggert/tz  
サポート状況:  開発中
種別:  データベース
ライセンス:  パブリックドメイン
公式サイト:  IANA — Time Zone Database  Sources for Time Zone and Daylight Saving Time Data（かつてのホームページ）
テンプレートを表示
Time Zone Database（元々はtz databaseと呼ばれていた）とは、IANAが管理している、世界各地域の標準時や常用時の等時帯（time zone、タイムゾーン）情報を収録したデータベースである。主にコンピュータ・プログラムやオペレーティングシステムでの利用を意図している。tz、tzdb、tzdata、zoneinfo databaseなどとも呼ばれる。
元々は、アーサー・デイヴィッド・オルソン（Arthur David Olson）が開始したプロジェクトであり、1980年代より複数のボランティアにより更新され続けていた。その事にちなみOlson databaseとも呼ばれる。2011年10月14日よりICANNのIANAが管理することとなった。ポール・エッガート（Paul Eggert）と Tim Parenti が現在のTime Zone Databaseの編集者兼管理者である。
最も目に付く特徴は、ポール・エッガートにより設計されたタイムゾーンの統一的命名規則である。例えば、"America/New_York"や"Europe/Paris"というような表記法である。データベースは、歴史的な（経年変化を記録した）タイムゾーンならびに1970年のUNIXエポックタイム（1970年1月1日0時0分0秒 UTC）からの、全ての常用時の変更を記録するよう企図されている。また、夏時間のような標準時の変化を示す遷移（transition）情報も含まれ、閏秒でさえも記録されている。
tz databaseには1970年からの地方時（local time, local clocks）が全く同一の地域となるよう分割して登録されている。この地図（シェープファイル）は、tz databaseバージョン2009rから取得したデータであるが、南極を除くすべての地域の等時帯が掲載されている。
歴史 > プロジェクトの起源

プロジェクトの起源は少なくとも1986年にまで遡る。データベース構築のためタイムゾーンや夏時間の履歴を調査するのに現在も使用している重要な情報源は、トーマス・G・シャンクス（英語版）（Thomas G. Shanks）により"ACS publications"から1978年以降数版刊行されているアトラス、The American Atlas並びにシャンクスとリック・ポッテンジャー（Rique Pottenger）によるThe International Atlasである。幾つかの参照用ソースコードも含め、プロジェクトのデータベースはパブリックドメインに置かれている。概ね年に数回、変更が必要となる場合にデータベースの新版が公開される。
歴史 > 訴訟（2011年）

「著作権法 (アメリカ合衆国)#著作権侵害と救済」および「著作権法 (アメリカ合衆国)#額の汗の法理」も参照
2011年9月30日、本データベースの著作権侵害を巡ってアストロレーブがオルソンおよびエッガードの2名を提訴した（「アストロレーブ・インコーポレイティッド対オルソン他事件」 Astrolabe, Inc. v. Olson et al.）。その結果、2011年10月6日（UTC）、tz databaseの維持管理並びに頒布の停止がオルソンより発表された。同時にメーリングリストの閉鎖も発表され、最新のアーカイブが配置されていたNIH内のFTPサイトの運営は停止した。オルソンのメールによると、「今回の閉鎖はtz databaseに関連する民事訴訟が同年9月30日に提起され」訴訟係属（"pending legal case"）にある為と述べている。一方アメリカ合衆国マサチューセッツ地区連邦地方裁判所（英語版）に提出された申立訴状（"complaint text"）によると、原告は"ACS Atlas"のデータを自社ソフトウェアに利用する企業、アストロレーブ（"Astrolabe"）であり、「tz databaseがアストロレーブが持つ著作権を侵害した」と主張している。
訴状によると、本件は先に述べた通りtz databaseが参考として使用している2つのアトラス、The American AtlasとThe International Atlasをtz databaseメンテナが著作物として利用したか否かという点が主な争点となる。とりわけ「tzメーリングリスト・アーカイブ」（タイムゾーン・メーリングリスト・アーカイブ。管理についての詳細は、節「管理」を参照）並びに当該データベースと共に維持管理されているいくつかの「補助的な連結収集物」（"auxiliary link collections"）に、アトラスの「データ」が「無断転載」（"unauthorized reproduction"）されたと原告は主張している。しかし、当該データベース自体は実際には申立の対象としてはなっていない。この申立ではタイムゾーン・データの経年変化を記録する「編集物」（"compilation"）のみが関係しており、現行のtz databaseの全世界のタイムゾーンを記録したテーブルは対象となっていない。
tz databaseは、構成ファイルのコメント・テキストを見れば分かる通り、タイムゾーン・データの利用の程度を検証できるよう、当該アトラスを含む情報源を明らかに参照している。このアトラスはtz databaseの構築に都合の良い（好ましい）情報源の一つである。そして当該データベースにアトラスから複製された「事実に基づくデータ」（"factual data"）が多く含まれている。著作権は通常「事実」（"fact"）に付随するものではないが、「創作的表現」（"creative expression"）に対しては発生し得るものであり、当該データベースは当該アトラスの断片を引用したのではなく、主としてタイムゾーン・データを独自の形式（フォーマット）で「複製した」（"reproduce"）のであり、一目見て訴訟申立の根拠は薄弱であると批判されている。加えて、タイムゾーン・データベース全体としても「著作性」（"copyrightable"）はない。その理由は、たとえタイムゾーン・データをアトラスに纏め上げるのに著しい作業量を伴うとしても、アトラスに掲載された情報は完全な事実の収集であり、それ故創作性は無い (これを「額の汗の法理」と呼ぶ) からである、と米国著作権法のあり方から見て通常結論付けられる。
2012年2月22日にアストロレーブはタイムゾーンデータが歴史的事実であることを認め、訴訟を取り下げた。
歴史 > IANAの管理前

tz databaseのコードとデータベース本体は、ボランティア集団により管理されていた。アーサー・デイヴィッド・オルソンはコードへ、ポール・エッガートはデータベースに、それぞれ最も多くの変更を加えた人物である。提案された変更点は、tzメーリングリストに送付される。このメーリングリストは、Usenetニュースグループのcomp.time.tzにゲートウェイを提供している。ソースコードはFTPサーバのelsie.nci.nih.govを経由して頒布される。一般に、これらのファイルはDebianのようなソフトウェア・ディストリビューターに採用され、事前コンパイルを行い、ソースコードとバイナリパッケージがディストリビューションの一部として収録される。エンドユーザーは、いくらか遅延を伴うものの、これらソフトウェア・ディストリビューションのアップデート手続きを頼りにするか、直接 ftp://elsie.nci.nih.gov/pub/ からソースコードを入手して、バイナリファイルを自分でビルドするかどちらかの手段をとることができる。
その当時の管理から、類似の方針を基にIANAによる管理へと移行する計画がIETFにより策定された。これはHTTPベースの通信プロトコルを利用する仕組みを持つとされる。
訴訟提起に基づき（"Pursuant to a lawsuit"）、オリジナルの頒布用FTPサーバとメーリングリストは閉鎖された。2011年10月7日、ICANNの有志（ケヴィン・ロバート・エルズ（英語版）ら）によりメーリングリストのアーカイブが複製され、一時的に仮メーリングリストが開設された。このメーリングリストは引き続きタイムゾーンのメンテナンスの為に利用される。2011年10月14日、IETFから要請を受け、正式にICANNが管理を引き継ぐと発表した。IETF議長ラス・ハウズリー（Russ Housely）は、商用システムを含む様々なソフトウェアでtz databaseが使用されている以上（注: 節"ソフトウェア・システムにおける利用"を参照）、管理が滞ることで起こりえる影響は計り知れない」と述べている。
歴史 > IANAへの管理移行

2011年10月14日、本データベースの管理はICANNのIANAへと引き継がれた。IANAはウェブページにて、著作権侵害の申立を受けているデータも含む完全なデータベースのコピーをオンライン上で公開しており、データベースの管理に関する現行ならびに今後の計画も同時に発表した。BCP 175 (RFC 6557) により Time Zone Database の管理の方法が規定されている。タイムゾーン・コンパイラ等のツール（"tzcode"）と生テキストのデータベース本体（"tzdata"）双方がIANA管理下のFTPサーバで頒布されている。
データ構造 > ファイルフォーマット

Time Zone Database はテキストファイルとして公開される。そのファイルは、人が可読な形式であり、ルールとタイムゾーンの遷移情報が一覧化されている。
利用に当たっては、プラットフォーム独立なバイナリファイルにコンパイルされる。バイナリファイルはタイムゾーン毎に1つずつ生成される。参照用ソースコードにはzic（zone information compiler）と呼ばれるコンパイラが付属しており、同時に、関数localtime()や
mktime()といった標準的なAPIを利用してコンパイル済みデータを読み込んだり、利用することができるコードも付属している。これらタイムゾーンの標準的なAPIは標準Cライブラリをはじめとして多くのライブラリに採用されている。とりわけ標準CライブラリはTime Zone Databaseの標準時データをテキスト生データからタイムゾーンコンパイラでコンパイルしてからデータをロードする。GNU Cライブラリ（glibc）とその派生物ではTime Zone Databaseのzicを改変したものを収録している。
Unix系システムでは、オペレーティングシステム・インストール時もしくは、適宜ユーザの指示によりシステム時刻の標準時を指定できる。概ねUTCまたはシステムが設置されている地域の標準時などその他任意の標準時を指定できる。設定の後システムは前述の通りタイムゾーン・テキストをコンパイルする。よってこの場合Time Zone Databaseのアップグレードを行う度にコンパイルし直す必要があるが、概ね現代的なパッケージ管理システムは標準CライブラリもしくはTime Zone Databaseを含むパッケージのアップグレード時に自動的に生テキストデータを再コンパイルする。組み込みLinuxなどのメモリの少ない環境では、コンパイル処理に時間がかかるため、コンパイル済みのパッケージを利用する場合もある。Debian 6.0（コードネーム; squeeze）などではこの方法を採用している。
データ構造 > タイムゾーンの定義

Time Zone Database において「タイムゾーン」（"time zone"）とは、1970年以来ずっと地域内の全ての時計が合っているような、国における地域のことである。この定義は、一貫した地方時を持つ地理的地域とまず最初に関係がある。これはグリニッジ子午線からの一貫した差分と関係がある他の定義とは異なる。それゆえ、Time Zone Databaseにより定義された各タイムゾーンは、場合によってはUTCからの時間の差分（協定世界時との差）を複数持つ。典型的には、標準時と夏時間双方が同一のタイムゾーンに含まれる。
データ構造 > タイムゾーンの命名規則

タイムゾーンは人間が理解しやすいようにするため、例えば"America/New_York"といったような"地域/地名"形式の固有の名称を持っている。また、その選択は英語名もしくはそれと等価な名前を利用するようになっており、名称の句読点や共通の接尾辞は省かれる。アンダースコアはスペースの代わりに利用される。地名部分におけるハイフンはそのまま用いられる。
データ構造 > タイムゾーンの命名規則 > 地域

「地域」（"Area"）とは、大陸名、大洋名、もしくは"Etc"という特殊な名前のいずれかを指す。大陸名と大洋名一式には現在、次が含まれる。アフリカ（Africa）、アメリカ（America）、南極（Antarctica）、北極（Arctic）、アジア（Asia）、大西洋（Atlantic）、オーストラリア（Australia）、ヨーロッパ（Europe）、インド（Indian）、太平洋（Pacific）。
"Etc"という特殊な地域は、幾つかの管理されるタイムゾーン、とりわけUTCを表す"Etc/UTC"のために使用される。POSIX形式、SUSに従うため、"Etc/GMT"を始めとするこれらのタイムゾーン名は、多くの人の予想とは正反対となる符号を持つ（比較のため、UTCのオフセットも参照せよ）。この形式では、タイムゾーン名の符号に関して、GMTから見て西側のタイムゾーンは、正の符号、東側は負の符号を持つ。例えば、Time Zone Databaseのタイムゾーン名"Etc/GMT-14"はGMTから14時間進んでいる、換言すれば、UTCから14時間分東のタイムゾーンに位置する（子午線から東回りに経度210度分進めたタイムゾーンに位置する）。すなわち、UTC+14と同じタイムゾーンを指している。
データ構造 > タイムゾーンの命名規則 > 地名

「地名」（"Location"）とは、該当地方内の特定の地名を指し、大抵都市や小規模な島嶼に当たる。このスキームにおいては国名は使用されない。主な理由として、政治的な変更や国境変更は頻繁にあるため国名を利用するスキームではデータの更新作業が煩雑になることが挙げられる。大都市の名前はより永続的な傾向がある。しかしながら、データベースの管理者は、ISO 3166-1 alpha-2(en:ISO 3166-1 alpha-2)国名コードのそれぞれにおいて、少なくとも1つのタイムゾーンを含むようにしており、そして、データベースへのユーザインタフェースの多くはこのことを利用している。加えて、将来タイムゾーンが変更された際に地域が異なるタイムゾーンに分断されないように地名の選択は地理的にコンパクトになるよう望まれている。[要出典]
通常、地名には、全体のタイムゾーンを代表するある地方の人口の最も大きい都市が選択される。しかしながら、幅広く知られている名前やより曖昧ではない名前を持つその他の都市が存在する場合、そちらが選択される可能性がある。[要出典]都市名が変更されたという場合においては、旧名と新規の名称双方が同じデータベース・エントリを指し示すようにするため、将来のバージョンにおいて「別名」（"alias", エイリアス）[要出典]を作成するという慣習がある。
時には「地名」がそれ自身、複合的な名称で表現される場合がある。"America/Indiana/Indianapolis（英語版）"というタイムゾーンがそのような例である。このような3段階形式の名称は現在、"America/Argentina/..."、"America/Kentucky/..."、"America/Indiana/..."、そして"America/North_Dakota/..."以下のゾーンにのみ存在する。
選択された地名は完全なその地域の代表となる。そのため、すべての都市名がその名にちなんで命名されるタイムゾーンを持つとは限らない。例えば、"America/Boston"というタイムゾーンは存在しない。更に、現時点で所属するタイムゾーンが同一であるが互いに異なる都市は、歴史的な意味で別名が付けられている場合（例えば、同じ標準時である"America/Detroit"と"America/New_York"の違い）や、または同じタイムゾーンに属するが異なる別々の都市が歴史的な意味で異なる国に分断された場合（例えば、旧チェコスロバキアの分裂による"Europe/Prague"と"Europe/Bratislava"の違い）により、たとえ現時点ではタイムゾーンが一致しているにもかかわらず、将来異なるタイムゾーン名を持つ可能性もある。
2010年5月1日、アーサー・デイヴィッド・オルソンは地名の文字数の限度を14に定めることを述べている。その理由は例えばバイア・デ・バンデラス（英語版）（Bahía de Banderas）のような地名から"de"を削り、識別子を"Bahia_Banderas"（データベース上ではAmerica/Bahia_Banderas（英語版））のみに限定することを正当化するためである。
データ構造 > タイムゾーンの命名規則 > 表記例

| --- | --- |
America/Costa_Rica（英語版）: 国名（コスタリカ）が使用されている。同国最大都市はサンホセであるが、英字名"San José"は様々な都市名（例: サンノゼ）で使われており不適当であるため。
America/New_York（英語版）: スペースはアンダースコアに置換されている。
Asia/Sakhalin（英語版）: 島名（サハリン）が使用されている。同島最大都市ユジノサハリンスクは英字名で"Yuzhno-Sakhalinsk"となり、Time Zone Databaseの制限である14文字以内の地名表記を超えてしまうため。
America/Bahia_Banderas（英語版）: 最大都市名であるが、正式名称「バイア・デ・バンデラス（英語版）」（"Bahía de Banderas"）から"de"が欠落している。これは正しい英字名称では14文字を超えてしまうため。
Antarctica/DumontDUrville（英語版）: 文字"'"（アポストロフィー）は除去されている。アンダースコアと置換せずスペースを除去するのは規則通りではないが、アンダースコアを付けると全部で15文字になってしまうため例外的にこのような名称になっている。
データ構造 > 各タイムゾーンのデータ格納

大抵は標準時と夏時間の遷移のことを指すが、UTCからの複数の時間差分を持つ各タイムゾーン向けに、Time Zone Database は時刻の遷移を正確に記録している。このフォーマットは、遷移の日時の変化も適宜調節できる。
データ構造 > 各タイムゾーンのデータ格納 > zone1970.tab

zone1970.tab はライセンスがパブリックドメインの Time Zone Database のファイルの1つである。かつては zone.tab が使われていたが、現在は zone1970.tab の方を使うことが推奨されており過去との互換性のために zone.tab が残されている。zone1970.tab にはタイムゾーンが一覧で記述されている。2014年7月19日までの zone.tab には、列、行が表す区分はファイル内のコメントに次のように記述されていた。
# This file contains a table with the following columns:
# 1.  ISO 3166 2-character country code.  See the file `iso3166.tab'.
# 2.  Latitude and longitude of the zone's principal location
#     in ISO 6709 sign-degrees-minutes-seconds format,
#     either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS,
#     first latitude (+ is north), then longitude (+ is east).
# 3.  Zone name used in value of TZ environment variable.
# 4.  Comments; present if and only if the country has multiple rows.
#
# Columns are separated by a single tab.
# The table is sorted first by country, then an order within the country that
# (1) makes some geographical sense, and
# (2) puts the most populous zones first, where that does not contradict (1).
参考訳:
# 当ファイルは次の各列要素から成る表（テーブル）で構成される:
# 1.  ISO 3166 2-文字による国名コード。詳しくはファイル`iso3166.tab'を見よ。
# 2.  タイムゾーンの主要都市の緯度、経度をISO 6709の
#     符号（+または-）-度（D）-分（M）-秒（S）フォーマットで表記。
#     フォーマットは+-DDMM+-DDDMMまたは+-DDMMSS+-DDDMMSSのいずれかを選択。
#     始めに北回りを正の符号にとる緯度、続いて東回りを正の符号にとる経度を記載。
# 3.  環境変数TZの値に含まれるタイムゾーン名を記述。
# 4.  コメント; 該当する国の記述が複数の行に渡る場合に限り記載。
#
# 各列要素は単一のタブで区切られる。
# 表の各行のデータは国名によってまず区分けられ、続いて、次の順序に従い各国のデータを並べ替える。
# (1) 幾つかの地理的な意義による、かつ
# (2) 最大の人口を持つゾーンを先頭に配置する。ただし(1)と矛盾しないようにすること。
区域 > 1970年以後での複数国に及ぶタイムゾーン

1970年以後において、2つの国に及ぶ地域を含むタイムゾーンが2つ存在する。tzdataはISO 3166-1の規格通りの国ならびに国名コードの定義に従っている（ISO 3166-1はその先行規格、ISO 3166を1974年に初めて公開している）。
Asia/Aden（英語版） - 1990年まではこのタイムゾーンは2つの国、北イエメン（英語版）、イエメン・アラブ共和国（首都サナア、ISO 3166-1: YE）と南イエメン（首都アデン、ISO 3166-1: YD, ISO 3166-3: YDYE）に分かれていた。
Europe/Berlin（英語版） - 1990年まではこのタイムゾーンは西ドイツ（ISO 3166-1: DE）と東ドイツ（ISO 3166-1: DD, ISO 3166-3: DDDE）に分かれていた。
区域 > 1970年以前のデータ

1970年より以前のデータに関しては、地域のタイムゾーンを同定する都市名を修正するよう注意を払っている。しかし、必ずしも地域全体でそのような修正が必要とは限らない。なぜなら1970年時点からの標準時を区別する場合にのみ、新しい地域が作成されるからである。
例えば、1963年10月23日から1963年12月9日までブラジル、ミナスジェライス州、エスピリトサント州、リオデジャネイロ州、サンパウロ州は夏時間制度を採用していた。しかし、1970年からの標準時はこの地域全体では同一であったため、タイムゾーンAmerica/Sao_Paulo（英語版）を分割する要求は却下された。
ドイツ時間の例では、トライゾーン内でベルリンと異なる夏時間を採用していた1945年に関しては、タイムゾーンEurope/Berlin（英語版）は正しい時刻を示していないとされる。[要出典]
区域 > 誤情報

かつて誤ったタイムゾーンが含まれていたケースがあった。とりわけ日本標準時における誤りについては、記事"日本標準時#South Ryukyu Islands時間"等を参照されたい。これは前述したThe International Atlasの第3版に誤った記述が含まれていたため起こった。
利用法と拡張 > タイムゾーンの境界

経緯度に基づく地理的な「境界線」（国境線ではない）の情報はTime Zone Databaseの一部ではない。しかしながら、境界線に関する情報は存在し、エリック・ミュラー（Eric Muller）が、Time Zone Databaseに収録されている「タイムゾーンに関する『境界線』」をベクター図形のイメージに表現したものを一般に公開している（上図）。このベクター図形を利用すると、地球上の経緯度上の各地点に位置づけられる、Time Zone Database上のタイムゾーンを決定できる。
利用法と拡張 > その他の標準の利用

CLDRはUN/LOCODEを地域同定に利用している。この実装は全ての識別子が国家を参照しており、Time Zone Databaseの開発元が避けたいと思っている事項も含まれている。
利用法と拡張 > ソフトウェアシステムにおける利用

Time Zone Database は多くのコンピュータシステム上でタイムゾーン処理とタイムゾーン変換のために利用されている。以下のような例が挙げられる。
Microsoft Windows 以外のほとんどのOSで使われている。マイクロソフトは独自に時間帯の情報収集を行っている。航空業界も独自のIATAタイムゾーンがある。
Unix系
BSDの派生システム、とりわけBSDの子孫と呼ばれる、FreeBSD、NetBSD、OpenBSD、DragonFly BSD。またmacOSも含まれる。これらのOSはTime Zone Databaseが処理するコードをOS固有の「TZ POSIX API実装」として参照している。
GNU Cライブラリとそれを利用するシステム。例えばGNUオペレーティングシステム (GNU Hurd) と大部分のLinuxディストリビューション、その他BeOS、Haiku、Nexenta OS、Cygwin。
System V Release 4の派生システム、例えばSolarisとUnixWare。
IBM AIX 6.1以降（初期のAIXのバージョン、とりわけAIX 5.2時点ではzoneinfoは含まれていた。これはMySQLのようなサードパーティーアプリケーションのサポートのためである。しかし実際にはそれは利用不可能だった）。
Tru64
UNICOS/mp
IRIX
OpenVMS
Java Runtime Environment。2002年の1.4リリースより利用している。
Perlモジュールである、DateTime::TimeZone、DateTime::LeapSecondが2003年より利用している。
PHPは2005年の5.1.0リリースより採用している。
Pythonは dateutil や pytz などのパッケージ。
.NET Frameworkは、Windows 以外では IANA の Time Zone Database が使われている。Windows では TimeZoneConverter や zoneinfoなどのライブラリ。
Embarcadero Delphi用モジュールのdelphi-tzdb。
Oracle Database。2004年の10gリリースから採用している。
PostgreSQL。2005年のリリース8.0から採用している。
ファームウェア内で利用するIP clocks、その他組み込みソフトウェア。
その他、Olson timezone IDというものがユニコードコンソーシアムのCLDR並びにICUで利用されている。例えば、「CLDR Windows → Tzid」テーブルは、Microsoft Windows time zone IDsから標準的Olson名へのマッピングを行う。
実例 > Unix系システム

Linuxディストリビューションをはじめとする多くのUnix系システムにおいて、タイムゾーンデータが格納されている標準的なディレクトリパスは/usr/share/zoneinfo/である。ファイルの形式識別用コマンドであるfile（英語版）は、次の実行例のように、バイナリ形式のタイムゾーンファイル内部からデータを読み出し、人間が理解しやすいテキスト形式で表示する機能をサポートしている。
$ file /usr/share/zoneinfo/Japan
/usr/share/zoneinfo/Japan: symbolic link to Asia/Tokyo
$ file /usr/share/zoneinfo/Asia/Tokyo
/usr/share/zoneinfo/Asia/Tokyo: timezone data, version 2, 4 gmt time flags, 4 std time flags, no leap seconds, 9 transition times, 4 abbreviation chars
Unix系システムにおいて、環境変数TZにTime Zone Databaseのタイムゾーンを指定しdateコマンドの出力結果が変化する様子を示す。シェルのロケールは日本（例: 環境変数LANG=ja_JP.UTF-8など）に指定されているものとする。またOSのインストール時に指定したタイムゾーンは日本標準時であるものとする。タイムゾーン設定はGNU Cライブラリでは/etc/localtimeファイルに保存され、コンパイル済みタイムゾーンデータは/usr/share/zoneinfoディレクトリ以下に保存されることが多いとされる。
dateコマンドは引数に何も指定しないで実行した場合、デフォルトではシステム時刻と/etc/localtimeのシステム・タイムゾーン設定を検知し両者を表示する。
$ date
2011年  1月 1日 土曜日 12:00:00 JST
日本標準時を明示的に指定する場合は以下となる。
$ TZ=Asia/Tokyo date
2011年  1月 1日 土曜日 12:00:00 JST
$ TZ=Japan date
2011年  1月 1日 土曜日 12:00:00 JST
フランスは中央ヨーロッパ時間（CET）を採用している。TZに指定した場合の結果は以下となる。
$ TZ=Europe/Paris date
2011年  1月 1日 土曜日 04:00:00 CET
フランスでは4月は夏時間施行期間であるため、3ヶ月後は、
$ TZ=Europe/Paris date -d '3 months'
2011年  4月 1日 金曜日 05:00:00 CEST
POSIX形式では、グリニッジ子午線の西回りを正の符号で表記する。符号に注意せよ。
$ TZ=Etc/GMT-9 date
2011年  1月 1日 土曜日 12:00:00 GMT-9
$ TZ=Etc/GMT+9 date
2010年  12月 31日 金曜日 18:00:00 GMT+9
TZに無効な文字列を指定した場合、すべて協定世界時（UTC）であると見なされる。
$ TZ=foo date
2011年  1月 1日 土曜日 03:00:00 foo
よくある間違いはTZにJSTと指定してしまうことである。これだとTZにUTCを指定した場合と同じになってしまう。POSIXのTZ環境変数の表記に合わせるならば、JST-9と指定しなければならない（符号の正負に注意せよ）。tz databaseの作者はtz databaseが利用できる環境ならば、このようなPOSIX表記を利用せずとも、最初に挙げたAsia/Tokyoのような〈大州〉/〈地域〉表記を利用した方が誤りを軽減できると述べている。
$ TZ=JST date
2011年  1月 1日 土曜日 03:00:00 JST
$ TZ=JST-9 date
2011年  1月 1日 土曜日 12:00:00 JST
タイムゾーンの設定（Debian）
コロイルCoAヒドロラーゼ

コロイルCoAヒドロラーゼ(Choloyl-CoA hydrolase、EC 3.1.2.27)は、以下の化学反応を触媒する酵素である。
従って、基質はコロイルCoAと水の2つ、生成物はコール酸と補酵素Aの2つである。
この酵素は加水分解酵素に分類され、特にチオエステル結合に作用する。系統名は、コロイルCoAヒドロラーゼ(choloyl-CoA hydrolase)である。
SGR 1806-20

| SGR 1806-20 | SGR 1806-20 |  |
| --- | --- | --- |

| SGR 1806-20の天球上での位置を示した図。 肉眼でこのように見えることはない。 | SGR 1806-20の天球上での位置を示した図。 肉眼でこのように見えることはない。 |  |
| 星座 | いて座 |  |
| 見かけの等級 (mv) | 非常に暗い |  |
| 分類 | 中性子星 |  |
| 位置 元期:J2000.0 | 位置 元期:J2000.0 |  |
| 赤経 (RA, α) |  18h 08m 39.32s |  |
| 赤緯 (Dec, δ) | −20° 24′ 39.5″ |  |

| 距離 | 15,000 パーセク |  |
| 物理的性質 | 物理的性質 |  |
| 半径 | 0.000025 R☉ |  |
| 質量 | 1.2391 M☉ |  |
| 自転周期 | 7.56 秒 |  |
| 光度 | <3.94×1013 L☉ |  |
| 他のカタログでの名称 | 他のカタログでの名称 |  |
| GRB 790107, INTEGRAL1 84, AX 1805.7-2025 GRB 970912, INTREF 882, CXOU J180839.3-202439, HETE Trigger 1566, KONUS 07.01.79, EQ 1805.7-2025, HETE Trigger 3801, PSR J1808-2024, GBS 1806-20, HETE Trigger 3800, RX J1808.6-2024 | GRB 790107, INTEGRAL1 84, AX 1805.7-2025 GRB 970912, INTREF 882, CXOU J180839.3-202439, HETE Trigger 1566, KONUS 07.01.79, EQ 1805.7-2025, HETE Trigger 3801, PSR J1808-2024, GBS 1806-20, HETE Trigger 3800, RX J1808.6-2024 |   |
| ■Template （■ノート ■解説） ■Project  | ■Template （■ノート ■解説） ■Project  |  |
SGR 1806-20は、史上一番初めに発見されたマグネターであり地球から約5万光年離れたC1 1806-20星団にある。
発見された当時はガンマ線を出す天体GB 970107として見つけられ、1986年に軟ガンマ線リピーターとして知られるようになった。1993年には、中性子星だと判明した。1998年パルサーだとわかると同時に、とりわけ強い磁場を持つことがわかり、マグネターであることが判明した。
位置

SGR 1806-20は、地球から見て銀河系の中心部をはさんで反対側、いて座の方向に約5万光年離れた位置にある星雲G10.0-0.3の中心部にあり、それに属するC1 1806-20星団は、銀河系最大のHII領域である[要出典]。1806-20星団には、知られている中で最も明るい恒星である高光度青色変光星LBV 1806-20や、炭素に富むWC9d型やWCL型のウォルフ・ライエ星など、珍しい恒星がいくつか含まれている