これはかなり一般的な質問であることはわかっていますが、私が見つけた答えが本当に問題を解決しているとは思えません。私は特定のユース ケースの概要を説明し、他の SO の回答や Web からの情報を要約します。
私が書いているサービスでは、データベース エントリが作成され、モバイル デバイスと Web サイトの両方に保存され、両方の方法で同期する必要があります。現在、リレーショナル データベースとして sqlite を使用する Android と iOS をターゲットにしています。サーバー側は、Django と MySQL を使用して Python で実装されていますが、将来的には他のソリューションがそれを置き換える可能性があります。
同期は、この SO 回答https://stackoverflow.com/a/5052208/2076094で概説されているアイデアに従って実装されます。同期には、サーバーによってのみ設定され、クライアントに同期されるタイムスタンプを使用します。オブジェクトの作成と更新には、last_synced_date とタイムスタンプを使用します。オブジェクトはユーザーが特定の時間に行ったことを参照するため、タイムスタンプ情報も持っています。
私の質問は、これらのタイムスタンプに使用される時間の内部表現のみに関するものです。UI のユーザー表現は、内部表現のローカライズおよびフォーマットされたバージョンです。実装言語と、タイムスタンプを表すために使用されるさまざまなデータベースの両方に、さまざまな方法があります。かなりの調査の後、有効な解決策しか残っていないようです。
- Unix 時間
- ISO8601
Hacker News に 2 回掲載されたこの記事では、UNIX 時間を使用することを提案しており、非常に優れた議論を示しています。予想されるように、HN に関する議論は、上記で概説した 2 つの点を中心にかなり分岐しています。
これまでの私の結論は、Unix タイムのタイムスタンプの方が扱いやすいということですが、Django では一般的な方法ではないようです。Djangoチュートリアルから他の多くのサイトまで、私が見つけたほとんどすべてのコード例は、models.pyでDateTimeFieldを使用しています。これは、SQLのある種の日付フィールドにマップされます。正確な用語は、使用するデータベースによって異なります。
送信と保存に ISO8601 日付を使用することの欠点は、それぞれの実装言語の Date 型を作成するために解析する必要があることです。それは難しいことではありませんが、ちょっと面倒です。私たちが使用している言語ごとに、(小さな) ライブラリが必要であるか、少なくとも必要以上のコードが必要です。あまりきれいではなく、依存関係を作成し、おそらく少し遅くなります。Unix タイムのタイムスタンプには、私が知っているどの言語でもその問題はありません。
もう 1 つのことは、データベースで (および解析中に) 「スマートな」日付フィールドまたはタイムスタンプ フィールドを使用すると、簡単に問題が発生する可能性があることです。物事を台無しにするタイムマジックに関して、SOには多くの質問があります。リンクの制限に達したため、投稿できませんが、簡単に見つけることができます ;)
タイム ゾーン情報を含まず、常に UTC を使用する単純化された形式を使用できます。とにかく UTC のみを使用しますが、ISO8601 を使用する場合は、普遍的に理解され、明確な形式を使用することもできます。Unix 時間は常に UTC であるため、心配する必要はありません。
もちろん、ISO8601 には生のデータベースを見ると人間が読めるという利点があり、2038 年の直前に数行のコードを書き直す必要はありませんが、それは欠点を補うものではないようです。
物事を書き出すことで、私は実際に私の答えをすでに持っているようです ;) とにかく、他の人がどう思っているか、自分のプロジェクトで何をしているのか知りたいです。他の人があなたの入力をより適切に分類できるように、ユースケースの簡単な概要を教えてください。
ありがとう！