使用每小时数据进行时间序列预测我刚刚看到 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) 可能是个好主意，这样他们就可以进行调查并可能将其记录为缺陷。
我希望这有帮助，
菲尔
