リアルタイムクロック
リアルタイムクロック（real-time clock、RTCと略記）は、コンピュータの時計であり、コンピュータの電源が切られていても現在時刻を刻み続ける機能のことを指す。また、その機能を持つ集積回路のことを指す場合もある。
概要
多くのコンピュータシステムで使われており、現在のパーソナルコンピュータや情報家電にはほぼ必ず組み込まれている。 組み込みシステムの分野では、リアルタイムクロックのことをカレンダークロックと呼ぶこともある。また、希であるが同分野でRTCといった場合、リアルタイム・コンピューティングを指すこともある。
リアルタイムクロックは、システム本体の電源装置とは直接はつながっていない特別なバッテリー（ボタン型電池や、電気二重層コンデンサなど）で駆動されることが多い（バッテリーバックアップ）。 つまり、リアルタイムクロック以外の機能はコンピュータの電源がオフの時は動作していないが、リアルタイムクロックの時計機能だけはバッテリーで動作している。 ただし、システム本体に供給される電源が無停電電源装置などによって停電保障されている場合は、システム本体と同じ電源でリアルタイムクロックを駆動するような設計が行われることもある。また、一次バッテリーをバックアップに用いる場合バッテリーの消耗を押さえるために、商用電源が断たれた場合のみバッテリー駆動するようリアルタイムクロックへの電源回路を設計することも行われる。
リアルタイムクロックは、コンピュータの、CPUや他の周辺機器（CPUクロックやシステムクロック）とは別のクロックジェネレータ（通常32768Hzなど、分周器によって1Hzを作り易い周波数のもので、主に時計用などとして生産・流通しているもの）で動作させることが多い。
リアルタイムクロックは「年」、「月」、「日」、「時」、「分」、「秒」をそれぞれデータとして提供する（これらに加え、曜日までカウントする機種もある）。つまり、一般にコンピュータ内で秒単位の時刻(C言語で用意されている標準変数time_t型など)を保持しているのとは全く別の方式である。これは同じチップをデジタル時計などにも利用しているためである。たとえば、あるリアルタイムクロックはそれぞれの値を2桁のBCDで保持している。このため使う側（例えばOS）が20世紀なのか21世紀なのか判断しなければならない（これも2000年問題の一種である）。たとえば1980年を基準とすると、80以上99以下なら1900年代、00以上79以下ならば2000年代といった処理を行うが、将来的に変更される可能性がある。年が2桁の情報で管理されている品種は、必然的に100年以上使われることを考慮していない。
コンピュータでの実際の利用
一般にリアルタイムクロックへの書き込み（つまり時刻あわせ）はコンピュータから見て非常に時間がかかる。 そのためネットワーク上で時刻同期するような場合でも、頻繁にRTCへ書き込まないような考慮をオペレーティングシステムが行っている。
現在のOSは起動時にRTCを読み取って、CPUの高精度（イベント）タイマーの精度を校正し、以後RTCから時刻を読み出すのではなく、高精度タイマーのカウンタ値によって時刻を保持している（カウンタ値を人間が理解できる形式にしたシステム時刻もあり）。これはRTCの時刻精度がおよそミリ秒が限度なのに対して、高精度タイマーはナノ秒からピコ秒の精度をもっており、より正確な時刻管理が出来るためである。特にこのような精密な時刻管理はNTPの様に「時計を正確な時刻に徐々に進める・遅らせる」といった操作には必要不可欠である（いきなり時計を戻すと、動作がおかしくなってしまうプログラムは多い。特にデータベースでジャーナルのタイムスタンプが乱れる事は、致命的な障害をもたらす）。
RTCがどの「標準時の時刻」であるかを知る術はない。なぜなら標準時（タイムゾーン）の情報が回路内に保持されていないからである[1]。システム時刻はブート時にRTCから時刻を同期する。しかし両者が参照するタイムゾーンに差異がある場合は注意深く同期しないと両者が何のタイムゾーン下の時刻であるかが分からなくなってしまう。まずOSのインストーラはシステム時刻の初回設定のため、RTC（インストーラによっては「ハードウェアクロック」と表示されている）がどの標準時を参照しているか（例えばJSTなのかUTCなのか）をユーザーに質問する。このためユーザーは何らかの方法でインストール前にRTCの「タイムゾーン」を調べなければならない。概ねBIOSのI/O コントローラー・ハブ(ICH)の設定にRTCの時刻が表示される。このBIOSの時刻表示にそれが何の標準時かは大抵表示されていない。このためユーザーは自分でテンプレート:仮リンクや時報とBIOSの表示時刻を比較し、RTCが何のタイムゾーンを参照しているか判断しなければならない。RTCの標準時が判明した、もしくは特定のタイムゾーン下の時刻となるようRTCを再設定した後、インストーラにRTCの標準時を指示しインストールを続行する。このRTCのタイムゾーン情報はOS・システム時刻のタイムゾーン情報（Unix系OSではいわゆるtz database）とは別個に保持される。具体的にUnix系OSでは前者は/etc/adjtime、後者は/etc/localtimeという別々の設定ファイルに分けて記録されている。この後、OSブートの度にRTCを読み出しシステム時刻がこれと同期される。Unix系OSではその際/etc/adjtimeファイルを見てRTCが何のタイムゾーンであるかを判断した上で同期する（ユーザーが/etc/adjtimeを操作したり、RTCのタイムゾーンが別のものであると強制的に認識させてシステム時刻を同期させることも可能。Linuxの場合は、詳しくはテンプレート:仮リンクコマンドを参照）。逆にシャットダウン時はシステム時刻をRTCに（RTCのタイムゾーンを認識した上で）書き込む[2]。以上よりUnix系OSではRTCに書き込む時刻をUTCまたはローカルタイムのどちらか一方をユーザーが選ぶことができる。一方、Windows NT系OSではRTCに(UTC に変更可能であるが、既定の設定では)ローカルタイムを書き込む。このため両OSをマルチブートできるシステムにおいて、仮にUnix系OS側がUTCで書き込んでいた場合、両者の間をマルチブートで往復するとRTCがタイムゾーンに応じて「狂ってしまう」（時差が発生する）。この問題に対して、Windows NT系ではUTCを使うという対策がある。しかし、時刻が直感的に判り難く、またローカルタイムの概念を持たないアプリケーションではタイムスタンプがUTCをローカルタイムとみなして保存するので都合が悪くなる。もしくはUnix系OS側をローカルタイムでRTCに書き込むようにすれば良い。
いずれの場合も、時刻源にRTCを使わず、NTPなど外部の時刻源に同期する様に設定するとほぼ問題無く時刻を参照できる（ただしMac OS X 10.4.xは時計が戻されるとFinderの動作がおかしくなるバグがある。AppleはMac OS X 10.5 Leopardへのアップグレードを推奨している）。
