私はそれを私の目的のために理解しました。私が学んだことを要約します（申し訳ありませんが、これらのメモは冗長です。他の何よりも将来の紹介に役立ちます）。
以前のコメントの1つで言ったこととは反対に、DATETIMEフィールドとTIMESTAMPフィールドは実行します。 動作が異なります。 TIMESTAMPフィールド（ドキュメントに示されているように）は、「YYYY-MM-DD hh：mm：ss」形式で送信したものをすべて受け取り、現在のタイムゾーンからUTC時間に変換します。データを取得するたびに、その逆が透過的に発生します。 DATETIMEフィールドはこの変換を行いません。彼らはあなたが送ったものを何でも受け取り、それを直接保管します。
DATETIMEフィールドタイプもTIMESTAMPフィールドタイプも、DSTを監視するタイムゾーンにデータを正確に保存することはできません 。 「2009-11-0101：30：00」を保存すると、フィールドには、必要な1:30 amのバージョン（-04：00または-05：00バージョン）を区別する方法がありません。
わかりました。データをDST以外のタイムゾーン（UTCなど）に保存する必要があります。 TIMESTAMPフィールドは、説明する理由により、このデータを正確に処理できません。システムがDSTタイムゾーンに設定されている場合、TIMESTAMPに入力した内容が元に戻らない場合があります。すでにUTCに変換したデータを送信した場合でも、データはローカルタイムゾーンにあると見なされ、UTCへの別の変換が行われます。このタイムスタンプが適用されたローカルからUTCへのバックからローカルへのラウンドトリップは、ローカルタイムゾーンがDSTを監視している場合、損失が発生します（「2009-11-0101：30：00」は2つの異なる可能な時間にマップされるため）。
DATETIMEを使用すると、任意のタイムゾーンにデータを保存でき、送信したデータを確実に取り戻すことができます（TIMESTAMPフィールドが押し付ける損失の多いラウンドトリップ変換に強制されることはありません）。したがって、解決策は、DATETIMEフィールドを使用し、フィールドに保存する前に使用することです。 システムタイムゾーンから、保存したい非DSTゾーンに変換します（UTCがおそらく最良のオプションだと思います）。これにより、変換ロジックをスクリプト言語に組み込むことができるため、UTCに相当する「2009-11-0101：30：00-04：00」または「2009-11-0101：30：」を明示的に保存できます。 00 -05：00"。
注意すべきもう1つの重要な点は、日付をDST TZに保存すると、MySQLの日付/時刻の数学関数がDSTの境界を越えて正しく機能しないことです。したがって、UTCで保存する理由はなおさらです。
一言で言えば、私は今これを行います：
データベースからデータを取得する場合：
正確なUnixタイムスタンプを取得するために、データベースからのデータをMySQLの外部のUTCとして明示的に解釈します。これには、PHPのstrtotime（）関数またはそのDateTimeクラスを使用します。 CONVERT_TZはあいまいさの問題がある'YYYY-MM-DDhh：mm：ss'値のみを出力し、UNIX_TIMESTAMP（）は入力は、データが実際に（UTC）に保存されたタイムゾーンではなく、システムのタイムゾーンにあります。
データベースにデータを保存する場合：
日付をMySQL以外で希望する正確なUTC時刻に変換します。例：PHPのDateTimeクラスでは、「2009-11-01 1:30:00 EST」を「2009-11-011：30：00 EDT」とは別に指定し、それをUTCに変換して、正しいUTC時間を保存できます。 DATETIMEフィールドに移動します。
ふぅ。皆様のご意見、ご協力に心より感謝申し上げます。うまくいけば、これにより他の誰かが将来の頭痛の種を減らすことができます。
ところで、これはMySQL5.0.22と5.0.27で見られます