使用每小時數據進行時間序列預測我剛剛看到 Jian Cao 舉辦的一個關於時間序列預測的非常有趣的網絡研討會，所以我想我會嘗試使用一個測試數據集，在這個數據集中，我在幾年中每三個小時記錄一次溫度。 但是，當我在時間戳中輸入日期和時間時，我收到一條錯誤消息：不支持的時間格式。 我在連續變量的“時間”輸入選項下嘗試了每種格式。 當然，JMP Pro 16 有一種方法可以跨多天每天每小時解釋一次，對嗎？
分析回复：使用每小時數據進行時間序列預測感謝你們對此的調查和解釋。 轉換為“最佳”格式的唯一問題是，出於某種原因，當您嘗試從數字字符串向後轉換為日期和/或時間（對於您預測的時間），日期和時間不正確！ 例如，當您使用此數據集預測 1000 秒，然後將“提前”時間轉換回時間格式時，年份是 1835 年而不是 2021 年。 吉姆是對的：最近的“秒”值是 3693752220，這意味著時鐘從 117 年前開始計時，所以是 1904 年。 我會詢問技術支持是否有一種解決方法不涉及在我的計算中使用自 1904 年以來的秒數。
回复：使用每小時數據進行時間序列預測這是一個有趣的花絮，謝謝吉姆。 當然 JMP 最初是為 Mac 設計的，所以與 Mac 的連接是有道理的。回复：使用每小時數據進行時間序列預測@txnelson誰知道？ 感謝您分享這一點點歷史。 我認為“危險邊緣”的編劇/製片人可以根據該解釋中的金塊創建一個完整的類別。
回复：使用每小時數據進行時間序列預測為了符合事實，JMP 日期時間值的起始時間 (紀元) 是 1904 年 1 月 1 日凌晨 12 點。我讀過的最好的解釋來自 LabVIEW 論壇上的 Pat Lavezza。LabVIEW 使用與 JMP 相同的紀元，起源可以追溯到蘋果電腦
“這是 1904 年 1 月 1 日的交易。 大多數（所有？）操作系統將時間存儲為自某個時間以來的秒數（或微秒等）。 這一次被稱為紀元。 Mac 可以存儲的秒數大約為 130 年。 程序員希望系統能夠覆蓋大多數用戶的生日，所以 epoch 需要從 20 世紀初開始。 那麼為什麼不從 1900 年 1 月 1 日開始呢？
Macintosh 設計人員需要將大量代碼壓縮到極少量的 ROM/RAM 中。 他們正在尋找可以為他們節省一些空間的任何類型的調整。 將紀元以來的秒數轉換為日期（如 1973 年 3 月 29 日）的代碼需要知道一年有多少天。 這意味著您需要代碼來確定一年是否是閏年。
如果年份是 4 的倍數，則為閏年除非是100的倍數除非它也是 400 的倍數。所以，1900不是閏年（100 的倍數），但 2000 年是（100 的倍數，也是 400 的倍數）。 通過避免使用 1900 年，Mac 設計師再也不必擔心閏年規則的 100/400 部分（因為 130 年的跨度只會涵蓋閏年 2000 年）。 如果年份是 4 的倍數，則為閏年。
那麼為什麼不是 1901 或 1902 或 1903 呢？ 通過從閏年開始，他們不需要“抵消”，這只是另一種節省一點空間的方法。
自從 LabVIEW 在 Mac 上啟動以來，它繼承了其中的一些怪癖。”
僅供參考，SAS 紀元是 1960 年 1 月 1 日
回复：使用每小時數據進行時間序列預測嗨安德森，
時間序列預測平台似乎需要日期或簡單的數字時間戳。 我認為它不適用於您的時間列，因為它是一種日期時間格式。
我將您的時間戳轉換為數字（格式 = 最佳），時間序列預測現在接受它（已附上）。 我認為這個數字時間戳是自 1970 年 1 月 1 日以來的秒數或類似時間。
我不確定為什麼時間序列預測不接受您的日期時間格式。 將此問題發送給 JMP 技術支持 (support@jmp.com) 可能是個好主意，這樣他們就可以進行調查並可能將其記錄為缺陷。
我希望這有幫助，
菲爾
