我想存儲時間作爲2013年1月1日和我保存在數據庫中的時刻之間的差異。它絕對比1970年的標準還要小）;無論是在儲存中還是因爲我在寄給客戶。格林威治標準時間與格林威治標準時間之間的時差現在格林威治標準時間和2013年1月1日gmt
因爲我打算做一個getRelativeTime（）相當多，我正在尋找簡單性。我可能會將其從2013年1月1日更改爲服務器啓動日期，即2013年1月的第一天：D
我保持客戶端和服務器端格式爲GMT，且位於nodejs服務器上，服務器未知。從我所研究的，有一些解決方案，但是很多人稱它們不正確，因爲這個和那個：|
您正在嘗試規範曆元時間的值嗎？這樣的歷元時間以正整數值給出。不是嗎？ 1356998400是您想要規範化的數據量。
提供一個有效的回答你的問題：
var ms = new Date() - Date.UTC(2013,0,1);
但請不要不做到這一點。
你最終會混淆使用你的系統（開發者，API客戶端，數據庫鄉親等）
，你認爲你將不保存以字節爲單位儘可能多的人。 JavaScript Number類型在內存中始終爲64位（8字節），see here。您可以在數據庫中保存多少數據非常依賴於您的數據庫平臺，但例如，MySQL DATETIME類型需要8個字節，而TIMESTAMP類型只需要4個。TIMESTAMP的範圍要小得多，請參考here和。
如果您的應用程序與您的時代之前的日期一起工作，您可能會經常遇到負數。他們會工作，但他們可能是混亂的來源。如果有人不知道你的調整時期，他們可能會產生一個日期，看起來有效，但應該是有所不同。
您也將拋棄使用許多期望日期以某種方式工作的優秀圖書館的潛力。你可以將你的自定義日期轉換爲標準日期，但是你是否真的想要不斷地打包和打開這些值？可能不會。即使像使用自己類型的moment.js這樣的庫，也可以通過擴展或封裝標準數據類型來實現。兼容性比字節空間要高得多。
有很多的東西錯了JavaScript的日期，但1/1/1970作爲一個劃時代的選擇是一個很好的東西。只是因爲你可以做點事情，並不代表你應該。
另外，考慮到磁盤空間通常是運行應用程序的最便宜的組件。即使有數百萬條記錄，您最多也可以節省幾十兆字節。我們只是錯誤地說錯誤，並說這個聰明的黑客可以節省200MB。亞馬遜的頂級預配置IOPS雲存儲每GB每月0.125美元。恭喜，你一年中節省了7.68美元。
1.客戶沒有看到它，只看到它的內部。 2.數百萬數據庫條目... 3.那麼如果有負數呢？ 4.如果我需要使用這些庫，我可以使用常規日期。 – Discipol
1.你可能會有開發者在你繼續前進之後。企業可能決定與第三方整合。你永遠不能確定未來會帶來什麼。 2.字段的字節大小更多地與精度和範圍有關，並且與您定位時期的位置有關。如果要保存數據庫空間，請使用精度較小的日期類型。 （你沒有提及你使用的數據庫。）另外，現在磁盤空間非常便宜。 –
@Discipol你如何將你的值存儲到數據庫中，以便節省一堆存儲空間？ – robertklep
無論時區如何，時差都是一樣的。 – karthikr