時間ごとのデータによる時系列予測Jian Caoによる時系列予測に関する非常に興味深いウェビナーを見たばかりなので、3時間ごとに数年間温度を記録するテストデータセットを試してみようと思いました。 ただし、タイムスタンプに日付と時刻を入力すると、次のエラーメッセージが表示されます：サポートされていない時刻形式。 連続変数の「時間」入力オプションの下で、すべての形式を試しました。 確かに、JMP Pro16が複数の日にわたって毎日1時間ごとに解釈する方法はありますか？
分析Re：毎時データによる時系列予測こんにちはアンダーソン、
時系列予測プラットフォームには、日付または単純な数値のタイムスタンプが必要なようです。 日時形式であるため、時間列では機能しないと思います。
タイムスタンプを数値に変換し（フォーマット=ベスト）、時系列予測がそれを受け入れるようになりました（添付）。 この数値のタイムスタンプは、1970年1月1日からの秒数かそのようなものだと思います。
時系列予測が日付と時刻の形式を受け入れない理由がわかりません。 これをJMPテクニカルサポート（support@jmp.com）に送信して、調査し、欠陥としてログに記録できるようにすることをお勧めします。
それがお役に立てば幸いです、
フィル
Re：毎時データによる時系列予測事実上正確に言うと、JMP日時値の発信時刻（エポック）は、1904年1月1日の午前12時です。私が読んだ最も良い説明は、LabVIEWフォーラムのPatLavezzaからのものです。LabVIEWはJMPと同じエポックを使用しており、起源はAppleコンピュータにまでさかのぼります
「これが1904年1月1日の取引です。 ほとんどの（すべて？）オペレーティングシステムは、特定の時間からの秒数（またはマイクロ秒など）として時間を保存します。 今回はエポックと呼ばれています。 Macが保存できる秒数は約130年でした。 プログラマーは、システムがほとんどのユーザーの誕生日をカバーできることを望んでいたため、エポックは20世紀初頭に開始する必要がありました。 では、1900年1月1日から始めてみませんか？
Macintoshの設計者は、非常に少量のROM / RAMに大量のコードを詰め込む必要がありました。 彼らは彼らにいくらかの部屋を節約することができるどんな種類の微調整も探していました。 エポックからの秒数を日付（1973年3月29日など）に変換するコードは、1年に何日あるかを知る必要があります。 つまり、年がうるう年かどうかを判断するためのコードが必要です。
4の倍数の場合、1年はうるう年です100の倍数でない限りそれが400の倍数でもある場合を除いて。だから、1900ではなかったうるう年（100の倍数）ですが、2000年は（100の倍数ですが、400の倍数でもあります）。 1900年を回避することで、Macの設計者はうるう年ルールの100/400の部分について心配する必要がなくなりました（130年のスパンはうるう年である2000しかカバーしないため）。 年が4の倍数の場合、うるう年でした。
では、なぜ1901、1902、1903ではないのでしょうか。 うるう年から始めることで、「オフセット」は必要ありませんでした。これは、スペースを少し節約するためのもう1つの方法です。
そしてLabVIEWはMacで始まって以来、それらの癖のいくつかを継承しました。」
参考までに、SASエポックは1960年1月1日です
Re：毎時データによる時系列予測@txnelson誰かわかったね？ このちょっとした歴史を共有してくれてありがとう。 「ジェパディ」の作家/プロデューサーは、その説明のナゲットからカテゴリー全体を作成できると思います。
Re: 毎時データによる時系列予測それは興味深い一口です、ジムに感謝します。 もちろん、JMP はもともと Mac 用に設計されたものなので、Mac との接続には意味があります。
