2013 年 1 月 1 日とデータベースに保存した瞬間との差として時刻を保存しようとしています。これは、1970 年に比べて作成の標準よりも確実に小さくなっています ;) ストレージと、クライアント側で送信しているためです。
getRelativeTime() をかなり頻繁に実行するので、単純さを求めています。2013 年 1 月 1 日から 2013 年の月の 1 日であるサーバーの起動日に変更する可能性があります :D
クライアントとサーバー側を GMT で追跡していますが、それは nodejs サーバー上にあり、サーバーは不明です。私が調査したところ、いくつかの解決策がありますが、多くの人はあれこれの理由で間違っていると呼んでいます :|
質問に対する有効な回答を提供するには:
var ms = new Date() - Date.UTC(2013,0,1);
しかし、これをしないでください。
システムを使用する人 (開発者、API クライアント、データベース関係者など) を混乱させることになります。
思ったほどバイト数を節約できません。JavaScriptNumberの型は常にメモリ内で 64 ビット (8 バイト)です。こちらを参照してください。データベースでどれだけ節約できるかは、データベース プラットフォームに大きく依存しますが、たとえば、MySQLDATETIMEタイプは 8 バイトしか必要としませんが、タイプTIMESTAMPは 4 バイトしか必要としませTIMESTAMPん。
アプリがエポックより前の日付で動作する場合、負の数が頻繁に発生する可能性があります。それらは機能しますが、混乱の原因になる可能性があります。誰かがあなたの調整されたエポックを認識していない場合、有効に見える日付を生成する可能性がありますが、別のことを意味するはずです。
また、日付が特定の方法で機能することを期待する多くの優れたライブラリを使用する可能性も捨ててしまいます。カスタム日付から標準日付への変換は可能ですが、これらの値を常にラップおよびラップ解除したいですか? おそらくそうではありません。独自の型を使用するmoment.jsのようなライブラリでさえ、標準のデータ型を拡張またはカプセル化することによってそれを行います。互換性は、バイト空間よりもはるかに重要です。
JavaScript の日付には多くの問題がありますが、エポックとして 1970 年 1 月 1 日を選択したのは良いことでした。何かができるからといって、そうすべきだというわけではありません。
また、ディスク容量は通常、アプリケーションを実行するための最も安価なコンポーネントであることを考慮してください。何百万ものレコードがあっても、せいぜい数十メガバイトしか節約できません。ハイサイドのエラーだけにして、この巧妙なハックで 200 MB 節約したとしましょう。Amazon の最上位のプロビジョンド IOPS クラウド ストレージは、1 GB あたり月額 0.125 ドルです。おめでとうございます。年間で 7.68 ドル節約できました。
エポック時間の値を正規化しようとしていますか? そのようなエポック時間は、正の整数値になります。そうじゃない？1356998400 は、正規化するデータの量です。