AppleサポートAppおよびYouTubeチャンネルのお知らせ
* iOS向けAppleサポートAppのバージョン5.6.1が公開されました。
* YouTube - Apple Japanチャンネルで有用なヒントや使い方を配信中です。
* iOS向けAppleサポートAppのバージョン5.6.1が公開されました。
* YouTube - Apple Japanチャンネルで有用なヒントや使い方を配信中です。
コミュニティでの投票方法と通知設定
コミュニティでの投票方法や通知の設定方法に関する記事を公開しました。
コミュニティでの投票方法や通知の設定方法に関する記事を公開しました。
Apple Account（Apple ID）の不正利用を確認する方法
Apple Accountに関するよくある質問についてはこちらのページを、また不正利用を確認する方法についてはこちらのドキュメントをご参照ください。
Apple Accountに関するよくある質問についてはこちらのページを、また不正利用を確認する方法についてはこちらのドキュメントをご参照ください。
写真データはiPhoto6をずっと使用していたのですが、
別な環境にデータをまとめて引っ越そうとしてデータを書き出したら
撮影日時の情報が無くなりiPhotoへ取り込んだ日になってしまい驚きました。
当然iPhoto上ではちゃんと正しい撮影日時は出ています。
多くの家族の思い出の写真データなので、
がんばって色々試したり検索したのですが、ここに頼る他ありませんでした。
こんな大切なことが出来ないはずはないと思っているので
私が無知なだけだと思いますが、ご教示頂きたく思います。
よろしくお願いします。
Mac OS X (10.4.11)
復元できました。お世話様でした。
＞トピ主さんの希望は「書き出したときのファイル作成日が撮影日時になってほしい」と言う事ですよね。
これも私の説明間違いで、
作成日ではなく「更新日が撮影日時になってほしい」です。すいませんでした。
で、Exifの撮影日を参照に更新日を一括変更できるソフトをみつけることが出来ました。（Windowsですが）
http://www.ryouto.jp/f6exif/table09.html
iPhotoで全てのデータを一つのフォルダーに書き出して、
Windowsに持っていき上記ソフトでフォルダー内一括変換しました。
私が間違った説明をしていなければ、
誰かが（やすどんさんあたりが）この方法をすぐに教えてくれたと思います。
コメントを頂いた皆様にはご迷惑をおかけし、申し訳ございませんでした。
また「Exifの撮影日を参照に更新日を変更」という発想が出来たのはこちらに相談したおかげです。
ありがとうございました。
復元できました。お世話様でした。
＞トピ主さんの希望は「書き出したときのファイル作成日が撮影日時になってほしい」と言う事ですよね。
これも私の説明間違いで、
作成日ではなく「更新日が撮影日時になってほしい」です。すいませんでした。
で、Exifの撮影日を参照に更新日を一括変更できるソフトをみつけることが出来ました。（Windowsですが）
http://www.ryouto.jp/f6exif/table09.html
iPhotoで全てのデータを一つのフォルダーに書き出して、
Windowsに持っていき上記ソフトでフォルダー内一括変換しました。
私が間違った説明をしていなければ、
誰かが（やすどんさんあたりが）この方法をすぐに教えてくれたと思います。
コメントを頂いた皆様にはご迷惑をおかけし、申し訳ございませんでした。
また「Exifの撮影日を参照に更新日を変更」という発想が出来たのはこちらに相談したおかげです。
ありがとうございました。
うまくいったようで何よりです。
（結局、新しいiPhotoの書き出しだと更新日は元に戻るかが分かりませんでしたが）
iPhoto'11では書き出した時点でのファイル作成日時になります。撮影日時はExifに残ります。
Exifが残っていればいいだろうと切り捨てられても仕方ないのかもしれませんね。
そのほかが切り捨てられたのではなく、撮影日時やそのほか写真にかかわるメタ情報を付属させるためにExifがあるのでそのExifを使えばいいのではって考え方だと思います。
アプリ制作側の方には更新日時が撮影日時として活用している人もいることを知っていただければ幸いです。
それはそのユーザの希望する利用法がそういった方法なだけでしょう。
あくまでもファイルの作成日はそのファイルの作成日ですし、ファイルの更新日時はそのファイルの更新日時なんです。決して撮影日時じゃないんですよね。
作成日時や更新日時とは全く別のメタ情報としてExifがあるのですからそのExifを参照すればいいでしょって事なんです。
ファイルやフォルダを名前や作成日時、更新日時などでユーザがマニュアルで管理するのはレガシーなやり方だと言うのが最近のAppleの考えみたいです。メタ情報を付属させておいてそのメタ情報に基づいて検索させる（iPhotoでいうスマートアルバムやiTunesでいうスマートプレイリスト等）方向に向かっていると思います。
今回はtakasatoさんの使用したい方法論とiPhotoが提供している使い方がマッチしていなかったので大変だったと思います。しかしそれらが完全にマッチする事はなかなか難しいので、ユーザがアプリに合わすか、または今回のようにツールを探してくるということになるでしょうね。
白熱しておりますが、本題に戻りましょう。
トピ主さんの希望は「書き出したときのファイル作成日が撮影日時になってほしい」と言う事ですよね。
まず今後もiPhotoの現バージョンを使う場合はこれはあまり問題になりません。iPhotoはExif情報を扱えますのでファイル作成日が撮影日時である必要はありません。
別の「Exifが扱えないアプリケーション」でiPhotoから吐き出した写真を扱いたいときの場合を考えます。対処方として
といったことが考えられます。
1.の場合は比較的簡単です。Exif情報の撮影日からリネームするユーティリティはありますのでそれを使えば一括変換が出来ます。例えばShupapan等があります。
http://sunsky3s.s41.xrea.com/shupapan/download/index.html
2.の場合はちょっと厄介ですね。私はファイル作成日を撮影日時に変換するユーティリティを知りません。ちょっとググってみたのですが「Appleスクリプトでできるんじゃない？」って言っている人がいるぐらいでスクリプトそのものは見つけれませんでした。Appleスクリプトを自力でかける人は出来るのでしょうかね。
ですので手っ取り早いところでは1.の方法で回避できれば楽だと思います。もしトピ主さんがどのような環境でどのようにファイルを扱いたいのかを具体的に書いてもらえれば妙案があるかもしれませんね。
iPhotoで書き出すと，書き出した日付になる仕様のようです。
iPhoto Libraryにあるオリジナルの写真データを複製されたら如何でしょうか。
当方，英語環境ですが，
メニューバーのGo>Home>Pictures>iPhoto Libraryを選択して右クリック>Show Package Contents>当該のオリジナル写真
（オリジナルデータの安全のために，目にふれにくくしていると憶測します）
「iPhoto Libraryを選択して右クリック>Show Package Contents」
というのは分かりませんでしたが、
私の環境ではiPhoto Library内Originals内が写真データになってるようです。
たとえば、iPhoto上で日付が2011年３月１１日を示している写真を
iPhoto Library内Originalsでは変更日・作成日共に2011年４月９日（取り込んだ日らしき日）になってます。
また、この写真をiPhoto上で「書き出し」すると（書き出されたデータは）
Mac上ウインドウでは変更日が2011年４月９日、作成日は1904年１月１日（作成日は無視な予感）になってます。
「情報を見る」では作成日は「--」（空）となり、変更日は2011年４月９日です。
更にこの書き込んだデータをWindowsXPで見ると更新日時は2011年４月９日で、作成日時はiPhotoから書き出しした日時です。
iPhoto上で正しい撮影日が出てるのでiPhoto Library内には撮影日は記録されてると思うので
iPhoto上で「書き出し」とある以上、編集してなければ取り込む前の写真に戻ると安易に考えてました。。
※ バージョン・OS環境によっては解決しているのであれば購入してでも対処したいです。
※ バージョン・OS環境によっては解決しているのであれば購入してでも対処したいです。
別な環境にデータをまとめて引っ越そうとしてデータを書き出したら
その別な環境が何であるのかを書いてもらえればお手伝いできるかも。
まず、iPhoto6は久しく使っていないので記憶が定かではありませんが、書き出す際にオリジナルで書き出すオプションはありませんか？。iPhoto9や11ですとあるのですが.....。こちらを利用できれば写真をオリジナルのまま吐き出すことができます。
また、オリジナル以外で吐き出してもEXIFはそのままで吐き出すはずなのですが、吐き出した画像ファイルのEXIFはどうなっているかチェックされてはいかがでしょう。
また別な環境がLionへの移行ということであれば、ライブラリをそのままiPhoto11での変換を試してみるとか。
iPhoto上で日付が2011年３月１１日を示している写真をiPhoto Library内Originalsでは変更日・作成日共に2011年４月９日（取り込んだ日らしき日）になってます。
写真情報（撮影日など）はEXIFに書き込まれているはずです。そのファイル自体をファインダーでみた状態の作成日（Mac上にいつ作成されたのか）とは別問題です。
> たとえば、iPhoto上で日付が2011年３月１１日を示している写真を
> iPhoto Library内Originalsでは変更日・作成日共に2011年４月９日（取り込んだ日らしき日）になってます。
それは仕方ないです。文句いうとしたらカメラメーカにいわないといけません。
ファイルの作成日などの情報を記録するのは、ファイルシステムです。MacOSXは HFS+ というファイルシステムで、ファイル作成日、変更日、最後にアクセスした期日などを記録しています。でもこれだけの情報を保持しているファイルシステムはそんなに多くありません。デジカメのsdカードなどはfatとかex fat とかを利用していますが、このファイルシステムではこれほどの情報を保持出来ません。そのため、カメラから写真を取り込むと、パソコンの方では、取り込んだ日の情報しかえられませんので、作成日はその日になります。情報を見るで、作成日が空白になっているとか、とんでもない日付になっているのは、元のファイルシステムが正しい情報を保持してないからです。写真には、EXIF情報があって、そこには写真を撮った日などの情報も記録されてますが、その情報はsdカードからのファイルコピーなどでは利用されません。ファイルシステムとしては、EXIF情報のような情報はどのファイルにも付属している情報というわけではありませんので、そんな情報をあてには出来ないのです。すくなくとも、sdカードがもっとまともなファイルシステムでファイルを保持していれば簡単に解決するのですが。
でも、hfs+ のファイルシステム並みの情報を保持しているファイルシステムというのは、unix とか ntfs のファイルシステムになります。広く利用されていて（読み書きが普通のパソコンで簡単に出来ることが条件）、これだけの機能を備えた、フリーで使えるファイルシステムというのはありませんね。Linux で利用されている ext3 などのファイルシステムなら、フリーで使えるのですけど、一般用途にはどこも使いませんね。素のままでは、Windows でも、MacOSX でも読み書き出来ませんし。
はに さんによる書き込み:
takasato さんによる書き込み:
> たとえば、iPhoto上で日付が2011年３月１１日を示している写真を
> iPhoto Library内Originalsでは変更日・作成日共に2011年４月９日（取り込んだ日らしき日）になってます。
それは仕方ないです。文句いうとしたらカメラメーカにいわないといけません。
ファイルの作成日などの情報を記録するのは、ファイルシステムです。MacOSXは HFS+ というファイルシステムで、ファイル作成日、変更日、最後にアクセスした期日などを記録しています。でもこれだけの情報を保持しているファイルシステムはそんなに多くありません。デジカメのsdカードなどはfatとかex fat とかを利用していますが、このファイルシステムではこれほどの情報を保持出来ません。そのため、カメラから写真を取り込むと、パソコンの方では、取り込んだ日の情報しかえられませんので、作成日はその日になります。
ここの部分ですが...。私は、デジカメの写真は、iPhoto 等を介さずに、まず SD カードや FD カードを Mac にマウントさせて、から自分で専用に作成してあるフォルダにドラッグ＆コピーでデータを移しています。また、iPhone の写真も DiskAid というユーティリティで、デジカメ同様、iPhone 内の写真フォルダ内の写真を選択してドラッグ＆ドロップでコピーしています。iPhoto や Aperture に登録するかどうかは、写真ごとに判断しています。つまり、iPhoto においても「取り込み」機能は使いません。（ここでスレ主さんが悩んでらっしゃるような色々な問題が発生するからです。また、最近はオリジナルの写真を撮り出すのも非常に手間がかかるようになってしまいました。）
で、Mac に取込んだファイルのタイムスタンプなどを確認すると、ちゃんとオリジナルのタイムスタンプのままです。（以前は iPhone の写真を DiskAid で取り出すと、コピー時の日時にタイムスタンプが替わってしまっていたのですが、ver. 4 か 5 辺りから改善されたようです。もちろん、タイムスタンプが替わってしまっても Exif データはちゃんと移動されているので...とは言え、フォルダ内でのソートやファイルを探す時に結構不便でした。でも、今はそれも改善されているようです。）
と言うわけで、カードからの直接コピーでは最初からそのような問題には遭遇しておりませんし、iPhone でも今ではそのような問題はなくなっています。もしもファイルシステムの問題で原理的にオリジナル・ファイルのタイムスタンプは移動できないということでしたら、私の環境ではいったい何が起こっているのでしょう？（反論しているのではありません。純粋に、どういう仕組みなんだろうということに興味があります。）
> もしもファイルシステムの問題で原理的にオリジナル・ファイルのタイムスタンプは移動できないということでしたら、私の環境ではいったい何が起こっているのでしょう？
それは簡単です。まともなファイルシステムでは、作成日、変更日、最後にアクセスした日時の情報がありますが、fat32 などの持っている情報をどのように割り当てるか（対応させるか）だけの問題です。いずれにしろ、fat ファイルシステムでは、現代的なファイルシステムが持っている程の情報を保持出来ませんので、何かの情報は落ちます。また、時間の記録方法も違いも問題になるかもしれません。MacOSX では、伝統的なunixの作法でやっています（1970.1.1 午前０時丁度からの時間を秒で記録）、Windows ではいろいろな時間があるようです。また、MacOSX では記録する時刻は、UTC で、読み出すときにその地の時差を考慮する方式ですが、Windows はローカルタイムが基本です。カメラの期日がどのように記録しているのか知りません（ローカルタイムっぽい感じはします）が、その辺も合わせておかないと正しい日時になりませんよね。
以前に比べると外国旅行は大変ポピュラーですが、写真の時間はJSTですね。これは不便だということで、カメラメーカ全体でUTCに変えたりするとまた大混乱ですね。
はに さんによる書き込み:
しい坊 による書き込み:
もしもファイルシステムの問題で原理的にオリジナル・ファイルのタイムスタンプは移動できないということでしたら、私の環境ではいったい何が起こっているのでしょう？
それは簡単です。まともなファイルシステムでは、作成日、変更日、最後にアクセスした日時の情報がありますが、fat32 などの持っている情報をどのように割り当てるか（対応させるか）だけの問題です。
すみません。どうも飲み込みが悪くて (^-^;)ゞ。
私も takasato さんも使用しているのは同じ Mac です。で、想像するに、２人ともデジカメの写真を Mac に取込んだのは同じだと思います。
takasato さんは iPhoto を使って取り込み、私は、直接ファイルのドラッグ＆ドロップで取込みました。
オリジナルのメディアはどちらの場合もたぶん FAT32 で、取り込み先は HFS+ で、この条件も同じだと思います。
それなのに、私の場合はオリジナルのタイムスタンプが残り、takasato さんの場合はコピー時の日時になってしまったわけです。あるいは、DiskAid でもかつては取り込み時のタイムスタンプになってしまっていたのが、今ではちゃんとオリジナルのタイムスタンプが残るようになっています。ここにいったい何があったのだろうかと...。
特に不思議なのは、素直にコピーすれば FAT32 のタイムスタンプが保存されるのに、なぜ Apple 純正の iPhoto ではタイムスタンプがわざわざ書き換えられてしまうのかが謎なのです。（何か、iPhoto のファイル管理上、そうすることにメリットがあるのでそうしているとしか思えません。）
いや、最初 はに さんが「タイムスタンプの移動は原理上できない」的なことをおっしゃっていたので、では、この現象はどのような現象なのだろうか、ということに興味を持っただけなのですが...。
MacOSX では、伝統的なunixの作法でやっています（1970.1.1 午前０時丁度からの時間を秒で記録）、
で、それ以前は当然マイナスで管理していると？（素人考えではそれなら、素直にユリウス日を使えばいいじゃないかって思ったりもしますが (^^;)。）
Windows ではいろいろな時間があるようです。また、MacOSX では記録する時刻は、UTC で、読み出すときにその地の時差を考慮する方式ですが、Windows はローカルタイムが基本です。
この Windows の仕組みって、文字コードの扱いからしてもそうなんですが、１台のパソコンは同じ国、同じ時間帯で、同じ１つの言語のみで使用する（しかもその使用する言語はユーザーは完璧にできる）という前提で作られているようで不便極まりないですね。外国から外国のローカル時間のタイムスタンプのファイルを受け取るということがあるという発想はないようですね。
カメラの期日がどのように記録しているのか知りません（ローカルタイムっぽい感じはします）が、その辺も合わせておかないと正しい日時になりませんよね。
ローカルタイムですよねぇ...。個人的には UTC と時間帯の両方の情報を保存して欲しいと思っています。それなら、19:00 (JST) -12:00 (CET)=-1:00 のような計算も簡単にできますしね。
以前に比べると外国旅行は大変ポピュラーですが、写真の時間はJSTですね。これは不便だということで、カメラメーカ全体でUTCに変えたりするとまた大混乱ですね。
写真の時間は別に JST というわけではなく、カメラに設定したローカルタイムなんだと思います。ですから、カメラのファイルのタイムスタンプが 12:00 となっていれば、日本でそのファイルをパソコンに取込めば、12:00 (JST)=03:00 (UTC) となり、中欧でそのファイルをパソコンに保存すれば、12:00 (CET)=11:00 (UTC) と解釈されてしまうだけだと思います。
Mac を使っている場合には、中欧滞在中にデジカメの写真を Mac に取込んでおかないと写真ファイルのタイムスタンプがおかしくなってしまいます。うっかり帰国してしまった場合には、ファイルを取込む時にだけ Mac の時間帯を中欧に変更してからコピーしなくてはなりません。
旅行中にカメラの設定日時を現地時間に変更することもありますが、これだと、どの時点で変更したかという問題が発生するので結構面倒です。それでも Mac の場合は手間が掛かりますが、時間帯の変更などの裏技で正確な UTC 時刻でファイルを保存することが可能なのですが、Windows の場合はいったいどうやるのでしょうね？（限りなくお手上げのような気がします...。）
私は基本的には（文字コードの Unicode 化と同様に）カメラの時刻管理も UTF＋時間帯 にすべきだし、たぶん、これからはそうなっていくのだろうなと想像しています。現在の CPU の能力をすれば、簡単に実現できることだと思います。将来的には iPhone のように GPS も搭載し、写真に現在位置を自動記録するのと同時に、時間帯の設定も自動化されると思っています。
日本のカメラメーカーが未だにそういう機能を実装していないのは、世界のウェブサイトのほとんどがもう Unicode 化しているのに、日本のウェブサイトは未だにほとんどが JIS (ISO-2022-JP) に固執しているのと同様で、メーカーの技術者たちがグローバルな発想を持てないでいるからに過ぎないと考えています。（「そんなこと簡単にできるけど、必要ないだろ？」と考えていると言うことですね。）
別に UTC にしたって、表面上は現地時刻で表示すればいいだけですからね。
> 素人考えではそれなら、素直にユリウス日を使えばいいじゃないかって思ったりもしますが (^^;)。
unix が生まれた頃（コンピュータが生まれた頃でもあります）は、コンピュータの能力も、今から思えば赤ちゃんみたいなものですから。システムの時間には32bit整数か何かを割り当ててました。1970.1.1 からの秒数でカウントしても、2036年（？）にはオーバフローするという規格です。そんな赤ちゃんにユリウス暦でカウントしろといわれても、、、なにせ、メーンメモリー4kbytesなんて珍しくない時で、１バイトが貴重だった頃ですから。
1970年より前はどうするのだという疑問には、時間というのは未来に向かって進むものですから、時計は過去のことは考えなくてよいのです。タイムマシンでも出来ない限り逆向きに進む時計は不要です。
はに さんによる書き込み:
しい坊 による書き込み:
素人考えではそれなら、素直にユリウス日を使えばいいじゃないかって思ったりもしますが (^^;)。
unix が生まれた頃（コンピュータが生まれた頃でもあります）は、コンピュータの能力も、今から思えば赤ちゃんみたいなものですから。システムの時間には32bit整数か何かを割り当ててました。1970.1.1 からの秒数でカウントしても、2036年（？）にはオーバフローするという規格です。
ああ、なるほど！ しかし、そうなると、これから「2036年問題」というのも発生するわけですね？ 64bit 整数とかで再定義となるのでしょうか？ それにしても IP アドレスの枯渇の問題と言い、リソースの問題があったとは言っても、何で“近い将来”簡単に移行できるようなシステムを構築してこなかったのでしょうね。（文字コードの Shift JIS のような工夫？）
1970年より前はどうするのだという疑問には、時間というのは未来に向かって進むものですから、時計は過去のことは考えなくてよいのです。タイムマシンでも出来ない限り逆向きに進む時計は不要です。
え、え、え!? まぁ、これはファイルシステムだけの問題だとは思いますが、そうなると、ミステリーなどで「おや、このファイルが作成されたのは1924年12月29日とありますね？ しかし、変ですねぇ？ この時代にはまだコンピューターは存在していなかったはずなんですけどねぇ？」なんていうシーンはありえないと言うことになるのでしょうか？ つまり、原理的に UNIX のファイルシステムでは 1969.12.31. 以前のタイムスタンプはありえないと...(^^;)？
> そうなると、これから「2036年問題」というのも発生するわけですね？
さすがに今は既に解決されてるはずです。ちょうど2000年問題が騒がれていた頃、この問題も騒がれてました。
でも、銀行なんかだと、今でも古いcobol か何かで動かしているものもあるという話です。（なので、銀行の送金ではいまだに半角カタカナで書かないといけなかったりします）。こういうシステムだと、怪しいかもしれません。
> リソースの問題があったとは言っても、何で“近い将来”簡単に移行できるような
> システムを構築してこなかったのでしょうね。
この辺になると、コンピュータの歴史そのものに深く関わり合います。もちろんおっしゃるようなシステムがよいに決まってます。当初は、コンピュータプログラムはアセンブラーで作っていたわけですが、それがCなどの高級言語で開発されるようになって来たのはまさにおっしゃるような理由のためです。Cのような高級言語でシステムソフトが書かれていれば、時計カウンターを32 bit 整数から64 bit 整数に変えるなんてのは簡単に出来ますから。でもアセンブラーで書かれていると、そんな簡単なこともすぐには出来ません。
> ミステリーなどで「おや、このファイルが作成されたのは1924年12月29日と
> ありますね？ しかし、変ですねぇ？ この時代にはまだコンピューターは存
> 在していなかったはずなんですけどねぇ？」なんていうシーンはありえない
> と言うことになるのでしょうか？
えっ、タイムスタンプが1924.12.29だったら、それはあり得ない（コンピュータ自体が存在しない）ので、後から偽造したものだということになるのでよいのでは？
でも、探偵はそんな昔の事件扱いますかね？
最初のコンピュータはアメリカが戦後間もない頃に開発したENIACだといわれてますが、ENIACには外部記憶装置はなかったとされてますので、ファイルというものも無かったのではないかと思います。イギリスが第２次大戦中に暗号解読のために同じ程度のものをもう少し早く開発していたということはいわれてます。
はに さんによる書き込み:
しい坊 による書き込み:
ミステリーなどで「おや、このファイルが作成されたのは1924年12月29日と
ありますね？ しかし、変ですねぇ？ この時代にはまだコンピューターは存
在していなかったはずなんですけどねぇ？」なんていうシーンはありえない
と言うことになるのでしょうか？
えっ、タイムスタンプが1924.12.29だったら、それはあり得ない（コンピュータ自体が存在しない）ので、後から偽造したものだということになるのでよいのでは？
いや、だから、ミステリーなので...(^^;)。探偵本人も「コンピューターが存在していない時代のものだ」と言っていますし。
でも、探偵はそんな昔の事件扱いますかね？
いや、事件自体は現在の事件です。そこで発見されたファイルのタイムスタンプが...という設定のつもりでした。探偵は...杉下 右京とか...(^^;)。
最初のコンピュータはアメリカが戦後間もない頃に開発したENIACだといわれてますが、ENIACには外部記憶装置はなかったとされてますので、ファイルというものも無かったのではないかと思います。イギリスが第２次大戦中に暗号解読のために同じ程度のものをもう少し早く開発していたということはいわれてます。
アメリカの SF 映画なんかだと、宇宙船がタイムスリップしたりした時に自動的に計器盤の日付が紀元前とかに変わってしまったりするわけです。私的には原理上宇宙船がタイムスリップ後の日時を知ることはできないだろうと考えているのですが。（タイムマシンならば別でしょうが、単に巻き込まれただけの宇宙船ですからね。）
いずれにせよ、現在のシステムではそれらの過去の日時を表現することは原理的にできないという理解でよろしいのですね？（素人考えでは「存在しなかったから、表現できなくても必要はないのだ」という切り捨て方は、なんか「2000年問題」や「2038年問題」と同じで、後で問題が発生するような気もするのですが...。いや、どういう時だと問われると困るのですが...。とっさにはさっきのミステリーのシチュエーションのようなものしか思いつきませんが...。）
> 現在のシステムではそれらの過去の日時を表現することは原理的にできないという理解でよろしいのですね？
いや、過去の日時を表現することは問題ないですよ。過去の時間を表すこと自体はコンピュータの動いているシステムには無関係ですから。あくまでも、コンピュータには1970年以前の過去の時間から動いている時計は無い、というだけの話です。時計と時間をごちゃごちゃにしないでください。コンピュータが過去の時間を扱えないなら、歴史を扱えないことになり（宇宙は130億年以上の歴史があるとされてます）、それはそれで困ったものです。
現在の物理学でも、逆向きに進む時計というのはありませんので、過去に向かう時計は考える必要がないのです。
撮影日を保守しながら書き出し
